Re: C++

[Jonathan S. Shapiro]

On Wed, Sep 23, 2009 at 11:51 PM, Tom Bachmann <address@hidden> wrote:

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.)

 

Three reasons:

1. For the kernel, we were turning off many compiler/language features. Most notably we turned of exception support, because the cost was high. At some point we realized that we were building in G++ rather than C++. For code that you want to assure, that is not allowed.
2. The bring-up complexity of the C++ library is considerable, and it is even more tightly dependent on streams support than the C library. Since EROS/Coyotos are not stream-oriented systems, that wasn't a good match.
3. Our ability to understand the code generation from C++ was noticeably weaker than our ability to understand the code generation from C.

So we dropped it for all of these reasons.

 

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.)

 

If you do, that is wonderful. Most programmers never learn.

 

Let me clear: I am not opposed to abstraction. In fact I am strongly in favor of it. But the benefits must always be balanced against the cost. In the type of code we were writing, which is fairly specialized, the benefits were *negative* and the cost was still high.