I want code that is Correct, Explicit, Fast, and in that order.

I'm 23 years old and learned C++ when I was 13.  Back then, my compiler didn't
even support "bleeding edge" C++ language features like namespaces.  I'm not a
C++ expert, and I don't have the ego to call myself a superb programmer.  The
largest program I've written is 10K SLOC in C.  Yet, I'd like to participate in
this discussion, if that is OKay =)

I do think I am capable of an honest critique of the downside of C++:

_Problems_ _With_ _C++_

 *size*
    On my bookshelf, most recent editions of the canonical C++ _books_:
        Accelerated C++: Practical Programming by Example (336 pages)
        The C++ Standard Template Library: A Tutorial and Reference (832 pages)
        Effective C++: 50 Specific Ways to Improve Your Programs and Design (288
pages)
        More Effective C++: 35 New Ways to Improve Your Programs and Designs
(336 pages)
        Exceptional C++: 47 Engineering Puzzles, Programming Problems, and
Solutions (240 pages)
        More Exceptional C++: 40 New Engineering Puzzles, Programming Problems,
and Solutions (304 pages) 
        The C++ Programming Language (1030 pages)
        Modern C++ Design: Generic Programming and Design Patterns Applied (352
pages)
        C++ Templates: The Complete Guide (552 pages)

    Altogether, that is 3918 pages.  K&R, the canonical C _book_, is 272 pages.
 Becoming a C++ language lawyer is much harder than becoming a C language
lawyer.  Language lawyers know "how not to hang oneself" while programming in
the language.  I don't know how many of these titles are translated to other
languages, however, I am sure the *effort* required to translate all of them is
significant.  Open source is more successful if there is a lingua franca for
programming, and that is C.  Now, it may move away from C over time, but it will
*never* be C++ because it's encyclopedic.

 *hidden complexity*
    (1) it's hard to say what code will compile down to.  viz., ...
[ message continues ]

One beef I have with C++ is its automatic conversion rules.  They were
obviously designed with two goals:

a) behave as C when not using user-defined types.  That's ok.

b) behave like Fortran in mixed-type expressions involving "complex"
   when using C++ (with any arbitrary user-defined type taking the
   role of "complex").

And b is just madness.  Not every user-defined arithmetic type is
complex.  I did some work using modular arithmetic (GF(65521) and
similar) and it was some hard work to keep values going through the
wrong arithmetic conversions.  Basically trial and error and reading
the generated assembly code and head scratching and standard-reading.

In short: the automatic conversions made it hard to express what one
wanted to get done, both for compiler as well as programmer.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
-

[ message continues ]