I have had some experience working with C++ and a couple other OOL's.
C++ does break down on complexity.  It goes a little bit like this:

C++ is extremely helpful in hiding implementation details and,
consequently, isolating implementation details into appropriate
areas of the code.  This encourages implementations to be cleaner
and is aesthetically pleasing to me.

C++ is extremely unhelpful in debugging by hiding implementation details
and, consequently, making it nigh on impossible to figure out what it
is doing while running a debugger.  I confess, tho, that this is in
an OS development environment where debugging is a bit trickier than
in app development.  I realize, also, that displaying the needed information
is a computable problem...it is just that:

> ``C++ compilers/tools are too buggy''
>
>  Yes, but they are getting better.

But much too slowly.  Perhaps with the stabilization of the language....

>  Yes, but compilers/tools are never quite good enough.

But of course :-)

>  Yes, but they have - often just barely - been good enough for real work.

I would argue strenuously that cfront was an excellent
proof of concept tool, but should never have been promoted
as anything else.

>  Yes, but they are still better than the alternatives on many platforms.
>
>  Most importantly, C++ and its various implementations have a solid
>  core where different compilers tend to agree and where the code
>  generated is reliably good.

I *must* take exception wrt cfront.  It is a ghastly, hopeless implementation
that muddles so much that I was *regularly* bumping into unimplemented/
buggily-implemented/poorly-implemented features.

>                              There are several ways of looking at
>  a language. If your job is to write a test suite or your aim is
>  to ``push the envelope'' of what can be done, you hit a lot of
>  annoying bugs and variation between implementations. If your job
>  is to build systems, you try hard to avoid the grey areas - and
>  often succeed.

When one is reading tutorials and reference manuals, it is not generally
pointed out which areas are "grey areas".  I would avoid "inline" like
the plague, except that when writing a Unix implementation, the code needs
to be effcient, and that means "inline" in many cases.  (And *that* means
cfront bugs, period, if you are saddled with it.)

The cause of all these bugs, of couse, is the complexity and occasional
ambiguity of the language itself.  I would presume that the majority of
the standards work has been on clarification "features" more than on
enhanced functionality (e.g. the "explicit" key word and counter proposal).

To me, what this all means is that C++ will remain difficult to use
(debug) until tools exist that can display all the needed debugging
information statically and at run time (really *good* browsers!!).
And, of course, we won't have to fret about the trash that one
certain well-known implementation generates.  Until then C++ is
aesthetically pleasing to me, but not as practical as C.
--
Bruce Korb       bkorb@mport.com
(408) 438-8649

Microport, Inc.