Re: a great C++ book?

["Dan Maas" <dmaas@dcine.com>]

> It's hard to explain a love/hate relationship with C++.  I think many
> systems programmers come to a point where they can "speak" C++ and do so
> in design conversations all the time, talking about the "objects" and the
> "methods", etc.  But they program in C. [...] The reality is that you want
> tp program in a fairly object oriented way but you also want to avoid
> "the creeping horror that modern C++ has become.".

These statements resonate very strongly with my experience... A few times
already I've said to myself "today is the day I start using C++ instead of
C." But every time I've turned back.

To be fair, most of the problems I encountered were
quality-of-implementation issues rather than problems with C++ the language.
(The only serious complaint I have about C++ the language is the lack of
opaque types -- yes, I know of the famous "pimpl" idiom, and find its syntax
and inefficiency rather disgusting).

If you read Stroustrup's "The Design and Evolution of C++," [book
recommendation =)] you will gain an appreciation of the effort the language
designers spent to ensure that C++ imposed no overhead for features that
aren't used. However, I've found that G++ and the associated GNU
implementation of the C++ standard library do not really deliver on this
promise. The assembly code output by G++ is often cluttered with seemingly
unnecessary cruft (way beyond the expected overheads of e.g. virtual table
indirections for virtual function calls). And don't even get me started on
all the gunk it puts in your symbol table (run nm(1) on any C++ object and
you'll see what I mean). (yes I know about -fno-exceptions and -fno-rtti)

You might say, "who cares about crufty assembly here and there, much less
symbol table pollution?" While these issues might not concern the typical
application developer, I care very much about cleanliness of my code, and I
know the Linux kernel hackers are very aware of how their C code interacts
with GCC...

I long for the day when I will be able to declare a struct member private,
use inheritance, and declare a local variable anywhere in a basic block in
my code... But I need to have a clean C++ compiler and library
implementation with true pay-as-you-go overheads before I make the switch.

Regards,
Dan