On Wed, Sep 23, 2009 at 11:51 PM, Tom Bachmann <[email protected]> wrote:
> Jonathan S. Shapiro wrote: > >> On Wed, Sep 23, 2009 at 9:45 AM, Tom Bachmann <[email protected] <mailto: >> [email protected]>> 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.
