[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++

From: Michal Suchanek
Subject: Re: C++
Date: Thu, 24 Sep 2009 10:08:31 +0200

2009/9/24 Tom Bachmann <address@hidden>:
> Jonathan S. Shapiro wrote:
>> On Wed, Sep 23, 2009 at 9:45 AM, Tom Bachmann <address@hidden
>> <mailto:address@hidden>> wrote:
>>    I strongly side with bas here. Even if you hate so many things about
>>    C++ (which I'm not going to argue about), the syntactic sugar for
>>    non-fancy OOP (i.e. class and method structure, single inheritance)
>>    is a sufficient reason to use C++ IMHO.
>>  That is certainly a credible argument for application code.
>>  For microkernel code, I can only tell you that we downgraded from C++
>> back to C in Coyotos, and that doing so simultaneously reduced complexity
>> and increased performance.
> That's interesting to hear. Any specific reasons? (When looking at the
> pistachio source every now and then, I think I can somewhat imagine why.)
>> For application code, the hazard is that all implementations of
>> abstraction involve indirection, indirection is slow, and all OO languages
>> have as a primary objective the seduction of young programmers into an
>> abiding love of gratuitous abstraction. And they succeed!
> Oh dear, I'm busted. Guess what language I learned first *g*. (Yes, it is
> C++, and yes, I subscribe to the "abstract whenever it makes your code look
> nicer" paradigm. But I think I also know when and how to break, or to omit
> in the first place, abstractions for performance.)

Well, the thing is that in many cases (actually most) writing, reading
updating and fixing the code is actually large part of the time the
code is processed. The actual run time (as opposed for idle time
waiting for user input or other event) is negligible for most code.

There are exceptions from this rule. Things like the kernel, libc,
libssl are used in all applications, including those that require to
actually perform some non-trivial number of transactions or
calculations. There are also things like media codecs that are
required to give results in realtime.

In some cases it is still more practical to get more hardware for the
job and have code that is easier to understand and fix than to have
code that is slightly faster.

As far as C++ goes I find some C++ code elegant but if it uses more
advanced C++ features I find it hard to understand. This may be just
because I do not work in C++ myself, though.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]