Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?) 
Author Message
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)

Bjarne Stroustrup <9758-26353> 0112760 (Fri, 9 Dec 1994) writes:

Just a few comments about Bjarne's article `Re: Widespread C++ Competency
Gap?'

Quote:
> This message is a response to a lot of outrageous inaccuracies, innuendo,
> rudeness, and flat-out false statements about C++ and its user community.

It must be extremely frustrating and aggravating when a reasonable
debate about a creation you care about, degenerates into a brawl.

Quote:
> The most dignified response would be a solid technical paper documenting
> the beauty and power of C++. However, people who believe even part of
> the rubbish posted about C++ will be unlikely to invest the time to get
> hold of such a paper and read it.

Some people would react that way.  But advocates of C++ could use it as a
weapon to help them in their defense of the language.  I would read it with
interest.  I encourage someone to write such a document.

Quote:
> Personally, I have found many stimulating ideas in Ada, Algol68,
> CLOS, Eiffel, ML, Modula-*, Smalltalk, Simula, etc. and in code
> written in those languages.

So have I.  But in all honesty, in the few 10's of thousands of lines of
C++ code I've read, and the 2 books and half a dozen papers, I've found
nothing that hasn't been better addressed in one or more of these
other languages.  But that's just my personal opinion.

`>'C++ is too complex''

Quote:

>    C++ is much more complicated than, say, C and Pascal. [...]

>    So, what about C++ is hard to learn, and why? [...]
>    The key concepts of data abstraction
>    and object-oriented programming are new to most people. [...]
>    However, becoming comfortable with OOP/OOD takes most people
>    much longer. Estimates of six to eigh{*filter*} month for becoming really
>    proficient are often quoted, are in line with my personal experience
>    with new C++ projects, and are in line with experience with other
>    languages supporting OO.

This is very telling, in my opinion.  I agree with most of what Bjarne
says, here.  But my experience of how long it takes programmers to become
proficient in this way, when shifting from C or Smalltalk to Objective C,
(to give a concrete example), is that it takes somewhere between a few
days and one month.

Much less, you note, than it takes to learn C++, in Bjarne's experience.

Quote:
>    So why do reasonably clever and experienced people sometimes fail
>    to learn C++ or fail to use it effectively after they have supposedly
>    learned it? Usually because they have the wrong expectations.

Another telling point.  A language which reasonably clever and experienced
people can fail to learn.  And the language designer admits this.
I hear warning bells.

Does anyone know of `reasonably clever and experienced people' who have
failed to grasp Objective C, in comparison?  In my view, this happens not
because of `wrong expectations', but because of inherent problems in C++.

[Bjarne's long explanation that you need teaching material to learn C++,
 and that it's easy to pick the wrong teaching material, deleted]

I agree - this is the situation.  Now, if C++ is a very complex language,
that would explain how this situation came about.  In my opinion,
_this_ is the correct explanation.

`>'C++ is useless/unreliable/dangerous because it lacks feature/property X''

Quote:

>    Also heard `as'you can't write real/reliable/maintainable/elegant/
>    re-usable/object-oriented/modern software without feature X - and C++
>    doesn't have X.''

>    Bosh!

[Bjarne's long explanation of adding language features into C++, and
 how people's criticism changed to some other `lack' after each addition,
 deleted.]

Again, in my opinion, this section reinforces my opinion that the _reason_
that C++ became as complex as it now is, was because Bjarne continually
added features because people said `C++ is no good because you can't <XXX>
with it.'  And especially, that he tried to make sure that you could
write code that would run as fast as the equivalent C code.

For me, that section explained _why_ C++ is too complex.

`>'C++ compilers/tools are too buggy''

Quote:

>    Yes, but they are getting better.
>    Yes, but compilers/tools are never quite good enough.
>    Yes, but they have - often just barely - been good enough for real
>    work.
>    Yes, but they are still better than the alternatives on many platforms.

I'd add:
        Yes, because the language is so complex it's extraordinarily hard
        to write a good compiler for it.

I mean, it's either that, or only bad compiler-writers were put to work on
the task.  I know  which explanation seems more likely to me.

Quote:
> Final comment:

>    In this note, I didn't try to present technical arguments
>    for (or against :-) C++. You can find many of my technical
>    arguments and opinions in my books and papers. Other good
>    sources of information about C++ and its use are the proceedings
>    of the USENIX C++ conferences`,'The C++ Report,'' Andy Koenig's
>    column in JOOP, and (to a lesser extent) the OOPSLA proceedings.

Are any of these online and ftp-able?

Quote:
>    In general, try to be a bit more tolerant and refrain from
>    hyperbole. We need an intellectual honest discussion and a
>    greater degree of professionalism in the discussion of
>    programming and programming languages.

Absolutely.

Some groups in the company I work for, use C++ and are very happy with
it.  Others dislike it just as strongly (I'm one of these).  Interestingly,
the turning point for me was the highly-educational internal `C++ Coding
Standard' document that was prepared in-house.  I read it with an open
mind, but it was this document, with it's 90 rules and 15-or-so pitfalls
and traps to avoid, that crystallised my current opinions on the language.

The document was written by highly experienced and intelligent C++ users,
who were also firm advocates of C++, as a matter of interest.

luke

PS: These opinions are my own, etc. etc.

--

Canon Information Systems Research Australia | Phone: +61 2 805 2982
P.O. Box 313 North Ryde, NSW, Australia 2113 | Fax:   +61 2 805 2929



Fri, 30 May 1997 14:41:58 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)

Quote:

>Just a few comments about Bjarne's article `Re: Widespread C++ Competency
>Gap?'

    what's this doing in comp.lang.c?  C++ is quite definitely
    not C.

    doesn't seem useful in comp.std.c++, either.
    Followup-To: generously hacked.

--xmsb




Sat, 31 May 1997 02:20:00 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)
A few comments on Luke Kendall's comments on Bjarne's article.

Bjarne> Personally, I have found many stimulating ideas in Ada, Algol68,
Bjarne> CLOS, Eiffel, ML, Modula-*, Smalltalk, Simula, etc. and in code
Bjarne> written in those languages.

Luke> So have I.  But in all honesty, in the few 10's of thousands of lines of
Luke> C++ code I've read, and the 2 books and half a dozen papers, I've found
Luke> nothing that hasn't been better addressed in one or more of these
Luke> other languages.  But that's just my personal opinion.

I agree with you: if you pick a problem and then hunt around for the
language you think solves it best, that language will probably not be
C++ -- expecially if you've decided you don't like C++ and pick your
problems on that basis.  The strength of C++ is not that it is the best
language for any particular thing, but rather that it is more than
adequate for a very wide range of applications.

So, for example, if your problem is to write a program that quickly and
portably copies files from one place to another, there is scant competition
for the C family (C, C++, and Objective-C).  Pascal will work too on some
machines but it fails the portability test.

On the other hand, if your problem is to write, say, a library for unbounded
precision arithmetic, the speed winner is probably compiled Lisp, especially
if it already has it built in.  Of course it can be done in the C family as
well, and here we find something interesting:

        Objective-C is probably easier than C to write but not as
                easy as C++ to use (because it has no operator
                overloading) and not fastest (because of the
                run-time overhead for using the object parts of Objective-C)

        C is hardest to write *and* hardest to use.  After all, if you
                can do it in C, you can do it the same way in either of
                the other two languages.

        C++ probably makes such a library about as easy to write as
                Objective-C and easier than C, and easier to use than
                either of the other two.  It is also probably the fastest
                of the three.

So can C++ solve this particular problem a well as Lisp?  Probably not.
Is it good enough?  Probably.  And it is the only language that solves
both these problems reasonably well.

Bjarne>      However, becoming comfortable with OOP/OOD takes most people
Bjarne>      much longer. Estimates of six to eigh{*filter*} month for becoming really
Bjarne>      proficient are often quoted, are in line with my personal experience
Bjarne>      with new C++ projects, and are in line with experience with other
Bjarne>      languages supporting OO.

Luke> This is very telling, in my opinion.  I agree with most of what Bjarne
Luke> says, here.  But my experience of how long it takes programmers to become
Luke> proficient in this way, when shifting from C or Smalltalk to Objective C,
Luke> (to give a concrete example), is that it takes somewhere between a few
Luke> days and one month.

Luke> Much less, you note, than it takes to learn C++, in Bjarne's experience.

I teach a summer course at Stanford with Barbara Moo.  We take people who
have used C but not C++ and make them proficient C++ programmers in a week.
If you read again what Bjarne said, you will see he was talking about how long
it takes people to become proficient designers -- and he is biased by seeing
mostly people who do not have the luxury of spending their time exclusively on
learning about design.

Bjarne>      So why do reasonably clever and experienced people sometimes fail
Bjarne>      to learn C++ or fail to use it effectively after they have supposedly
Bjarne>      learned it? Usually because they have the wrong expectations.

Luke> Another telling point.  A language which reasonably clever and experienced
Luke> people can fail to learn.  And the language designer admits this.
Luke> I hear warning bells.

Perhaps you should have your ears checked :-)

It takes about as long to learn C++ as it does to learn to drive a car.
Some people never learn to drive well; others get into all kinds of trouble
in the process.  Does this mean that cars are a bad idea?

Luke> Does anyone know of `reasonably clever and experienced people' who have
Luke> failed to grasp Objective C, in comparison?  In my view, this happens not
Luke> because of `wrong expectations', but because of inherent problems in C++.

People who report no failures either have few users, are being less than
forthright in their reporting, or are trying nothing that might fail--that
is, nothing interesting.  I don't know Objective-C, but because I don't
think it's a toy, I'm confident there are some failures out there if one
would look for them.

Luke> [Bjarne's long explanation that you need teaching material to learn C++,
Luke>  and that it's easy to pick the wrong teaching material, deleted]

Luke> I agree - this is the situation.  Now, if C++ is a very complex language,
Luke> that would explain how this situation came about.  In my opinion,
Luke> _this_ is the correct explanation.

Yes, but popularity alone is enough to explain it -- a popular language
attracts people who want to make money from teaching it and half those
teachers will be worse than average.

Luke> `>'C++ is useless/unreliable/dangerous because it lacks feature/property X''
Bjarne>
Bjarne>      Also heard `as'you can't write real/reliable/maintainable/elegant/
Bjarne>      re-usable/object-oriented/modern software without feature X - and C++
Bjarne>      doesn't have X.''
Bjarne>
Bjarne>      Bosh!

Luke> [Bjarne's long explanation of adding language features into C++, and
Luke>  how people's criticism changed to some other `lack' after each addition,
Luke>  deleted.]

Luke> Again, in my opinion, this section reinforces my opinion that the _reason_
Luke> that C++ became as complex as it now is, was because Bjarne continually
Luke> added features because people said `C++ is no good because you can't <XXX>
Luke> with it.'  And especially, that he tried to make sure that you could
Luke> write code that would run as fast as the equivalent C code.

There is a design philosophy behind C++ and Bjarne has been consistent
about rejecting ideas that were not consonant with that philosophy.
He did not just add everything that anyone could think of.  Indeed,
the list of things that have been proposed for C++ and rejected is huge.

Luke> For me, that section explained _why_ C++ is too complex.

No it doesn't, actually, because `too complex' is an opinion in the guise of fact.
Too complex for what?  Complexity is something that can be traded off against
other things such as speed and utility.  Saying C++ is too complex without
a context is like saying a Boeing 747 is too heavy because it weighs 400 tons.
Too heavy for what?  Too complex for what?  In this case, it's too complex
for Luke's taste.  That's OK -- there's no disputing taste.  But the right
tradeoff for Luke is not necessarily right for everyone.

Luke> ``C++ compilers/tools are too buggy''
Bjarne>
Bjarne>      Yes, but they are getting better.
Bjarne>      Yes, but compilers/tools are never quite good enough.
Bjarne>      Yes, but they have - often just barely - been good enough for real
Bjarne>      work.
Bjarne>      Yes, but they are still better than the alternatives on many platforms.

Luke> I'd add:
Luke>        Yes, because the language is so complex it's extraordinarily hard
Luke>        to write a good compiler for it.

Luke> I mean, it's either that, or only bad compiler-writers were put to work on
Luke> the task.  I know  which explanation seems more likely to me.

I don't think C++ compilers are any more buggy than any other widely
distributed commercial software.  For instance, I've used a VERY popular
WYSIWYG word processor in which the position of the cursor on the screen
sometimes deviates by up to several characters from the place on the
screen where characters appear when I type them.  It is hard for me
to understand how such a bug could ever be allowed to happen -- but
there it is.

Maybe the lesson is that one should buy only products that are so closely
associated with a single vendor that there is no competition likely, either
now or the near future.  Then hope that vendor doesn't go out of business
because if it does, it will take you down in flames with it.

No thank you.  I will live with the occasional bug and urge people to
pester their vendors to think more seriously about quality -- in C++ and
everywhere else.  Consider yourself urged.

Bjarne> Final comment:
Bjarne>
Bjarne>      In this note, I didn't try to present technical arguments
Bjarne>      for (or against :-) C++. You can find many of my technical
Bjarne>      arguments and opinions in my books and papers. Other good
Bjarne>      sources of information about C++ and its use are the proceedings
Bjarne>      of the USENIX C++ conferences`,'The C++ Report,'' Andy Koenig's
Bjarne>      column in JOOP, and (to a lesser extent) the OOPSLA proceedings.

Luke> Are any of these online and ftp-able?

No, but you can buy them.  Also (plug alert), there is a good chance that
next year there will be a book of my columns available.

Bjarne>      In general, try to be a bit more tolerant and refrain from
Bjarne>      hyperbole. We need an intellectual honest discussion and a
Bjarne>      greater degree of professionalism in the discussion of
Bjarne>      programming and programming languages.

Luke> Absolutely.

And we need to distinguish opinions from facts more carefully.  In my opinion.

Luke> Some groups in the company I work for, use C++ and are very happy with
Luke> it.  Others dislike it just as strongly (I'm one of these).  Interestingly,
Luke> the turning point for me was the highly-educational internal `C++ Coding
Luke> Standard' document that was prepared in-house.  I read it with an open
Luke> mind, but it was this document, with it's 90 rules and 15-or-so pitfalls
Luke> and traps to avoid, that crystallised my current opinions on the language.

There are pitfalls in every language.  All it takes is a large enough
body of experience to bring them out.  Don't let lack of experience --
in any language -- lull you into ...

read more »



Sat, 31 May 1997 01:00:32 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)
[I read Bjarne Stroustrup's article in defence of his "baby"
with great interest.  I have never said C++ "sucks", but in
my own small way I have occasionally dropped some words of
innuendo against the language.  C++ has always fascinated
me, in a "love/hate" kind of way.  That's why I was unable
to repress the urge of writing and posting this article,
against my better knowledge, perhaps.]

Sorry, Bjarne,  or:

Why C++ Is Not My Favorite Programming Language
===============================================

Object Oriented Programming is a powerful and elegant concept, comparable
in its scope and impact with previous break-throughs like the list-
manipulation model (Lisp) or the block-structured model (Algol).  
Clearly, not every problem lends itself easily to list manipulations,  
and not everything is a block.
Similarly, objects are not the solve-it-all of programming.   A lot
can be accomplished using the OO approach (both things that have already
been done in other ways, and novel, undiscovered stuff), but it's very
easy to let oneself be captivated by the new paradigm and forget about
reality.  Like the the case (Ellis/Stroustrup, ARM, p. 164) of the
programmer who used an empty base class because (s)he "suspects that two
classes have something in common, but hasn't yet determined exactly
what" :-).

Smalltalk
=========

C++ differs quite a lot from Smalltalk in the way the OOP model is
implemented.  Maybe more important in practice is the lack in C++ of
a standard class library like Smalltalk has.  This forces C++ programmers
to become class implementors, or to become the captives of their compiler
vendors, each offering a non-standard, non-portable set of classes.
Even if a standard class library for C++ is being considered now, it
may already be too late.   One is reminded of Algol 60's lack of
standard I/O facilities, except of course that Algol was not
introduced as an "I/O oriented language"...

There is a big difference between fundamental class design and
application design.  An average C programmer can get quite a lot
done using the stdio and other library facilities that the language
provides.  It takes an above-average programmer to actually implement
their own stdio (or iostream) library.  I fear that a lot of energy
of well meaning C++ programmers is being wasted on reinventing square
wheels.  This defeats the whole purpose of OOP, which is supposed to be
all about code reusability and quick & easy application development.

Simula
======

C++ inherits more from Simula than from Smalltalk in the way
objects are implemented (you could say that Smalltalk is more like
"friend" language than a [virtual] base one).  Both approaches have their
pros and their cons, in brief: speed and safety vs. flexibility.
The flexibility can be partly regained in C++ (and Simula) by
the use of "virtual" functions.  But the whole concept is
philosophically "backwards".  How can the parent foresee all
the possible needs of his children?  In practice, there is no
real problem: many things follow clearly from the problem at hand,
and if something unforeseen *does* happen, the library implementor
(and since C++ does not have a standard library, that's likely
to be you :-) can always add "virtual" to the base class method,
recompile and be done with it.  That doesn't make it pretty, though.

I don't know much about the proposed "runtime type identification"
proposals, but the name would seem to implicate that Smalltalk-
like runtime flexibility is going to be retrofitted in the language
after all.

C++
===

Programming language choice is always a matter of taste, too.  
Personally, I prefer the implicit way Simula handles object
"construction", by inserting statements into the class body itself,
after the instance variables and function definitions (much like Modula
modules and Ada packages initialize themselves).  If struct/class
variables were allowed to have initializers (as in Ada), the need for
many constructors would disappear.  But these are just different flavors
of syntactic sugar.  Garbage collection would also be nice to have,
if only because it would eliminate the need for destructors (along with
their weird notation).

What I do like about C++ are: classes (!), function prototypes,
easier handling of struct and union names ("automatic typedef",
"anonymous unions"), default arguments, inline functions, templates...
All these features indeed make C++ "a better C".

The reputation C++ has of being a complex language is due mainly to
the features that were added to allow object oriented techniques
while retaining C syntax.  In order for class objects to behave
like "real" C++ types, a mechanism had to be provided to define
and overload existing operators and functions.  Reference types were
needed to implement object creation, initialization and assignment.
These things were inevitable.  They opened up a can of worms, however.
In the name of orthogonality references to ordinary variables are also
allowed (e.g. as arguments to functions).  The simple C rule that calling
a function will not modify your variables, unless you pass an address (or
your variable is an array, of course) is subverted, a problem that will
make code maintenanace more difficult and error-prone. Also, new
notations have to be introduced (::, ::*, .*, ->*, yet another &, etc.).    
The net result is that Objective C code, with its blatant departure

"normal" C than a complex C++ class implementation.

This is a pretty consistent pattern in C++: features added for very
good reasons (ease of use, one of them) end up having almost the opposite
effect.  Exception handling is a case in point.  Why implement exception
handling?  Because the old familiar pattern of:

    if(call()==error) {
        do_something();
    } /* etc. etc.*/

is tedious, wasteful and error-prone.  An exception-handling mechanism
should be the exact opposite of this, and syntactically as simple as
possible.  I doubt if requiring a try{} block is the right approach.
And passing arbitrary data to an exception handler is nice, but not
essential.  Now everybody will start writing their own exception classes...
Yet more complexity and overhead!

C
=

The preceding has shown that, as a C programmer, I have my doubts
about C++ being one better than C.  Some of the good things about
C++ have made it back into the ANSI C Standard, like function
prototypes.   On the other hand, I really wish they hadn't bothered
with "const" (now was that "char *const" or "char const *" or "const
char *"?).  And if C++ had really wanted to improve on C, then why
haven't they done anything about the one thing in C that's really
broken by design: the "switch" statement?  I propose:

    inspect(e) {

        ....;
        /* no break; */
    default: ...
    }

But I haven't yet revealed the real, fundamental and unnegotiable
reason why I don't like C++:  name mangling.

I quote (ARM, p. 122): "Originally designed to implement overloading
of functions [OK, I can dig that], name encoding is now a common technique
for providing type-safe linkage".  

Only it isn't.  I quote again (p. 126):

"Types of variables are not encoded in their names, nor are the return
types of functions [the one thing K&R C always _tried_ to check, for
Christ's sake] encoded."  

The encoding scheme discussed in the ARM is not standard: every vendor
can (and does) implement this in their own way.  I thought one of the stated
objects of C++ was being as compatible as possible with C.  Now it's not
even compatible with itself.  What happened to (object) code reusability?
Yes, I know, you can export functions as extern "C"... yet another ugly
language extension.  

And what is the rationale given for this name mangling (or "decoration" as
it is euphemistically called)?  I quote again (p. 122):

"Unfortunately, linkers are usually rather low-level programs with limited
notions of type, they differ dramatically from system to system, and they
are among the hardest programs in a system to change (because everybody
depends on them)."  

I don't buy it.  On PC-like systems (or even Unix), linkers are not that
difficult to replace.  I honestly don't know about linkers on other
architectures:  would that be the same linkers that require ANSI C to
limit the number of significant characters in external symbols to
6 characters, all uppercase?  Try fitting __ct__1xFv (constructor for
class x) into that!  But the point is immaterial, really: no amount of
effort would have been excessive if only name mangling could have
been avoided: it's evil.  If you can write debugging info into your
object files, you can write type information into them.  Just add a
wrapper around the brain-dead linker, and you're done.  Is that so
difficult if you're already building a compiler?  A final quote (p. 127):

"... making a C++ implementation 100% type-safe -- would require either
linker support or a mechanism (an environment) allowing the compiler
access to information from separate compilations."  

Exactly!  And *NO* name mangling, please!!

--
Miguel Carrasquer         ____________________  ~~~
Amsterdam                [                  ||]~  



Sat, 31 May 1997 11:14:36 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)

Quote:

>A few comments on Luke Kendall's comments on Bjarne's article.

>Bjarne> Personally, I have found many stimulating ideas in Ada, Algol68,
>Bjarne> CLOS, Eiffel, ML, Modula-*, Smalltalk, Simula, etc. and in code
>Bjarne> written in those languages.

>Luke> So have I.  But in all honesty, in the few 10's of thousands of lines of
>Luke> C++ code I've read, and the 2 books and half a dozen papers, I've found
>Luke> nothing that hasn't been better addressed in one or more of these
>Luke> other languages.  But that's just my personal opinion.

>I agree with you: if you pick a problem and then hunt around for the
>language you think solves it best, that language will probably not be
>C++ -- expecially if you've decided you don't like C++ and pick your
>problems on that basis.  The strength of C++ is not that it is the best
>language for any particular thing, but rather that it is more than
>adequate for a very wide range of applications.

Is this supposed to comfort people who are using C++?  Unfortunately,
being second best seems to be a widespread attitude in the US: it may not
be the best, but it works nearly as well as the leading brand.

[deletia]

Quote:
>Luke> Another telling point.  A language which reasonably clever and experienced
>Luke> people can fail to learn.  And the language designer admits this.
>Luke> I hear warning bells.

>It takes about as long to learn C++ as it does to learn to drive a car.
>Some people never learn to drive well; others get into all kinds of trouble
>in the process.  Does this mean that cars are a bad idea?

Meaningless text bite.  Citations?  How does driving a car compare to
programming in C++?  Let's compare languages to langauges and cost of
delivering software -- then you can deterimine with tangible evidence
what is good and bad.  All other comparisons are emotionally loaded.

[more deletia]

Quote:
>Luke> [Bjarne's long explanation that you need teaching material to learn C++,
>Luke>  and that it's easy to pick the wrong teaching material, deleted]

>Luke> I agree - this is the situation.  Now, if C++ is a very complex language,
>Luke> that would explain how this situation came about.  In my opinion,
>Luke> _this_ is the correct explanation.

>Yes, but popularity alone is enough to explain it -- a popular language
>attracts people who want to make money from teaching it and half those
>teachers will be worse than average.

Another meaningless text bite.  Consider, for example, the SAT company
recently decided to lower the score for a 50th percentile ranking on next
year's SAT tests.  Does this mean when more people score above 50% that
they are smarter than last year?

50% worse than average is a worthless statement unless you can show that
the average teacher indeed is worthwhile.  If 100% of the people are
teaching that no destructors should ever be virtual, then what does that
say about your average teacher?

Quote:

>Luke> For me, that section explained _why_ C++ is too complex.

>No it doesn't, actually, because `too complex' is an opinion in the guise of fact.
>Too complex for what?  Complexity is something that can be traded off against

Too complex for the 'average' (your words) teacher to teach effectively.  
If the language cannot be passed on in a manner which causes the majority
of the students to use it effectively and to its full potential, then
perhaps it could be considered too complex.

Quote:
>Luke> ``C++ compilers/tools are too buggy''

[deletia]

Quote:
>I don't think C++ compilers are any more buggy than any other widely
>distributed commercial software.  For instance, I've used a VERY popular
>WYSIWYG word processor in which the position of the cursor on the screen
>sometimes deviates by up to several characters from the place on the
>screen where characters appear when I type them.  It is hard for me
>to understand how such a bug could ever be allowed to happen -- but
>there it is.

Pointless justification.  It is illogical to deem the bugs in C++
compilers acceptable simply because other software is buggy.  The compiler
needs to be compared to the langauge document not to a WYSIWYG editor.
(And, as a silly side remark: maybe the software doesn't work because the
compiler didn't work?)

[deletia about BS' books and positions about C++]

Quote:
>Luke> Are any of these online and ftp-able?

>No, but you can buy them.  Also (plug alert), there is a good chance that
>next year there will be a book of my columns available.

The Design and Evolution of C++ is quite good in that it shows some of
what was kept and some of what was rejected -- and why.

Taylor Hutt



Sat, 31 May 1997 21:19:59 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)

: > Personally, I have found many stimulating ideas in Ada, Algol68,
: > CLOS, Eiffel, ML, Modula-*, Smalltalk, Simula, etc. and in code
: > written in those languages.

: So have I.  But in all honesty, in the few 10's of thousands of lines of
: C++ code I've read, and the 2 books and half a dozen papers, I've found
: nothing that hasn't been better addressed in one or more of these
: other languages.  But that's just my personal opinion.

        I think you missed one of Bjarne's points; every language does
some things very well.  We could probably take almost ANY language X
and, if we examine it's features individually, have a good chance of
findin another language that does that better..  You have to look at a
language as a whole, and decide weather it's practical to use in a
large project.  The gact that C++ has been used in so many large
projects recently speaks for itself.

        However, I must disagree; I like many of c++'s features, and
have yet to find a language that does many things so nicely.  But
that's just my opinion.

: `>'C++ is too complex''
: >
: >         C++ is much more complicated than, say, C and Pascal. [...]
: >
: >         So, what about C++ is hard to learn, and why? [...]
: >         The key concepts of data abstraction
: >         and object-oriented programming are new to most people. [...]
: >         However, becoming comfortable with OOP/OOD takes most people
: >         much longer. Estimates of six to eigh{*filter*} month for becoming really
: >         proficient are often quoted, are in line with my personal experience
: >         with new C++ projects, and are in line with experience with other
: >         languages supporting OO.

: This is very telling, in my opinion.  I agree with most of what Bjarne
: says, here.  But my experience of how long it takes programmers to become
: proficient in this way, when shifting from C or Smalltalk to Objective C,
: (to give a concrete example), is that it takes somewhere between a few
: days and one month.

: Much less, you note, than it takes to learn C++, in Bjarne's experience.

        Well, I think that Bjarne has different standards for
proficency than you do.  I've had people who have been coding in C(
not C++ mind you! ) for many years write incorrect code because they
misunderstood a feature, or have to have me explain what I was doing
with part of my code, again because they didn't understand a basic
language feature.  And "C" is a very simple language!

: >         So why do reasonably clever and experienced people sometimes fail
: >         to learn C++ or fail to use it effectively after they have supposedly
: >         learned it? Usually because they have the wrong expectations.

: Another telling point.  A language which reasonably clever and experienced
: people can fail to learn.  And the language designer admits this.
: I hear warning bells.

        Well, he goes on to explain why, but you seem to have
skipped this..  I personally feel it's an unwillingness to shift
to the OOP paradigm.

: Does anyone know of `reasonably clever and experienced people' who have
: failed to grasp Objective C, in comparison?

        I don't know anyone who knows objective C reasonably well.

: In my view, this happens not
: because of `wrong expectations', but because of inherent problems in C++.

        Hmm.. I feel that the fact that there are probaby 50 C++ programmers
for every objective C programmer an indication that C++ is 50 times better.
The fact that objective C is such a failure is because of inherent
problems in it's design.

 < The above has several invisible smileys >

: Again, in my opinion, this section reinforces my opinion that the _reason_
: that C++ became as complex as it now is, was because Bjarne continually
: added features because people said `C++ is no good because you can't <XXX>
: with it.'  And especially, that he tried to make sure that you could
: write code that would run as fast as the equivalent C code.

: For me, that section explained _why_ C++ is too complex.

        Too complex for what?  I don't know, but the reason I like C++
is because it often runs as fast as equivalant C code, and is good for
many purposes.  But I guess I'm just foolish enough to want a
powerful, fast language.

--
------------------------------------------------------------------------------

| Laboratory for advanced computing      |      My employer barely KNOWS me. |
------------------------------------------------------------------------------
And at that point, he did not know if he was a man who had been
imagining he was a god or a god playing at being a man.  Thus was his
illumination perfected.



Sat, 31 May 1997 08:14:31 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)

Comments on Miguel Carrasquer's comments on Stroustrup:

Miguel> [I read Bjarne Stroustrup's article in defence of his "baby"
Miguel> with great interest.  I have never said C++ "sucks", but in
Miguel> my own small way I have occasionally dropped some words of
Miguel> innuendo against the language.

...such as the innuendo in the very first line of this message.

Miguel> C++ has always fascinated
Miguel> me, in a "love/hate" kind of way.  That's why I was unable
Miguel> to repress the urge of writing and posting this article,
Miguel> against my better knowledge, perhaps.]

Miguel> Sorry, Bjarne,  or:

Miguel> Why C++ Is Not My Favorite Programming Language
Miguel> ===============================================

No problem -- if it's your second or third favorite, that's fine.  :-)

Miguel> Object Oriented Programming is a powerful and elegant concept, comparable
Miguel> in its scope and impact with previous break-throughs like the list-
Miguel> manipulation model (Lisp) or the block-structured model (Algol).  
Miguel> Clearly, not every problem lends itself easily to list manipulations,  
Miguel> and not everything is a block.
Miguel> Similarly, objects are not the solve-it-all of programming.   A lot
Miguel> can be accomplished using the OO approach (both things that have already
Miguel> been done in other ways, and novel, undiscovered stuff), but it's very
Miguel> easy to let oneself be captivated by the new paradigm and forget about
Miguel> reality.  Like the the case (Ellis/Stroustrup, ARM, p. 164) of the
Miguel> programmer who used an empty base class because (s)he "suspects that two
Miguel> classes have something in common, but hasn't yet determined exactly
Miguel> what" :-).

Indeed, objects do not solve all problems.  That's why C++ allows
people to use other programming styles as well where appropriate.

Miguel> Smalltalk
Miguel> =========

Miguel> C++ differs quite a lot from Smalltalk in the way the OOP model is
Miguel> implemented.  Maybe more important in practice is the lack in C++ of
Miguel> a standard class library like Smalltalk has.  This forces C++ programmers
Miguel> to become class implementors, or to become the captives of their compiler
Miguel> vendors, each offering a non-standard, non-portable set of classes.
Miguel> Even if a standard class library for C++ is being considered now, it
Miguel> may already be too late.   One is reminded of Algol 60's lack of
Miguel> standard I/O facilities, except of course that Algol was not
Miguel> introduced as an "I/O oriented language"...

Lack of a good standard library is Bjarne's biggest regret in the
design of C++.  On the other hand, the picture is nowhere near as grim
as you are painting it because there are several commercial libraries
available that are not tied to any particular compiler vendor.  True,
using such a library does tie you to the library vendor in a sense,
but library vendors generally do make source code available.

Of course C++ started out with the C library and rapidly acquired
an I/O library of its own.  The new standard library, which people
are already beginning to implement, is a major step forward.

Perhaps a more interesting question: how long would it have been worth
delaying C++ to make a standard library available?

Miguel> There is a big difference between fundamental class design and
Miguel> application design.  An average C programmer can get quite a lot
Miguel> done using the stdio and other library facilities that the language
Miguel> provides.  It takes an above-average programmer to actually implement
Miguel> their own stdio (or iostream) library.  I fear that a lot of energy
Miguel> of well meaning C++ programmers is being wasted on reinventing square
Miguel> wheels.  This defeats the whole purpose of OOP, which is supposed to be
Miguel> all about code reusability and quick & easy application development.

It does not, however, defeat the whole purpose of C++, which is about
making it possible for professional C programmers to program more
abstractly than they can in C.

So far, your article contains no fundamental criticism.

Miguel> Simula
Miguel> ======

Miguel> C++ inherits more from Simula than from Smalltalk in the way
Miguel> objects are implemented (you could say that Smalltalk is more like
Miguel> "friend" language than a [virtual] base one).  Both approaches have their
Miguel> pros and their cons, in brief: speed and safety vs. flexibility.
Miguel> The flexibility can be partly regained in C++ (and Simula) by
Miguel> the use of "virtual" functions.  But the whole concept is
Miguel> philosophically "backwards".  How can the parent foresee all
Miguel> the possible needs of his children?  In practice, there is no
Miguel> real problem: many things follow clearly from the problem at hand,
Miguel> and if something unforeseen *does* happen, the library implementor
Miguel> (and since C++ does not have a standard library, that's likely
Miguel> to be you :-)

More innuendo.

Miguel> can always add "virtual" to the base class method,
Miguel> recompile and be done with it.  That doesn't make it pretty, though.

So is the whole point of this long paragraph that virtual functions
aren't `pretty?'  Or is it objecting to the difficulty of modifying
programs when the authors of the originals didn't anticipate that
modification?  If the latter, I strongly suspect that any language will
have problems in allowing people to modify programs contrary to
the original authors' (lack of) intentions.

Miguel> I don't know much about the proposed "runtime type identification"
Miguel> proposals, but the name would seem to implicate that Smalltalk-
Miguel> like runtime flexibility is going to be retrofitted in the language
Miguel> after all.

More innuendo.  First you object because the language doesn't do
what you want, then you object because it does.

Miguel> C++
Miguel> ===

Miguel> Programming language choice is always a matter of taste, too.  
Miguel> Personally, I prefer the implicit way Simula handles object
Miguel> "construction", by inserting statements into the class body itself,
Miguel> after the instance variables and function definitions (much like Modula
Miguel> modules and Ada packages initialize themselves).  If struct/class
Miguel> variables were allowed to have initializers (as in Ada), the need for
Miguel> many constructors would disappear.  But these are just different flavors
Miguel> of syntactic sugar.  Garbage collection would also be nice to have,
Miguel> if only because it would eliminate the need for destructors (along with
Miguel> their weird notation).

More innuendo.  Why do people get so hung up over syntax?  If it looks
weird, that means you haven't used it enough to understand it.
This is true of every programming language I have seen, not just C++.

That said, I agree that GC would be nice to have, if there were a
way to do it without giving up anything else.  The best bet so far
seems to be one of the conservative collectors.  I am personally
not fond of conservative collectors, because they are inefficient at
reclaiming memory compared with copying collectors -- but if you
like them, then by all means use them.

Miguel> What I do like about C++ are: classes (!), function prototypes,
Miguel> easier handling of struct and union names ("automatic typedef",
Miguel> "anonymous unions"), default arguments, inline functions, templates...
Miguel> All these features indeed make C++ "a better C".

... and templates are more powerful than most people realize.

Miguel> The reputation C++ has of being a complex language is due mainly to
Miguel> the features that were added to allow object oriented techniques
Miguel> while retaining C syntax.  In order for class objects to behave
Miguel> like "real" C++ types, a mechanism had to be provided to define
Miguel> and overload existing operators and functions.  Reference types were
Miguel> needed to implement object creation, initialization and assignment.
Miguel> These things were inevitable.  They opened up a can of worms, however.
Miguel> In the name of orthogonality references to ordinary variables are also
Miguel> allowed (e.g. as arguments to functions).  The simple C rule that calling
Miguel> a function will not modify your variables, unless you pass an address (or
Miguel> your variable is an array, of course) is subverted, a problem that will
Miguel> make code maintenanace more difficult and error-prone. Also, new
Miguel> notations have to be introduced (::, ::*, .*, ->*, yet another &, etc.).    

I have heard this criticism often, yet people who have had to maintain
large bodies of C code and then of C++ code generally report that the
C++ code is easier to maintain.  Maybe it has to do with how well the
code is written -- in which case I would rather choose a language based
on the best it can do rather than the worst.

Miguel> The net result is that Objective C code, with its blatant departure

Miguel> "normal" C than a complex C++ class implementation.

Indeed.  I hesitate to comment on a language of which I know so little,
but Objective-C appears to me to be two separate languages under one roof.
That is an interesting approach, but if I had the luxury of choosing two
languages I think I would make C++ one of them rather than C.

Miguel> This is a pretty consistent pattern in C++: features added for very
Miguel> good reasons (ease of use, one of them) end up having almost the opposite
Miguel> effect.  Exception handling is a case in point.  Why implement exception
Miguel> handling?  Because the old familiar pattern of:

Miguel>     if(call()==error) {
Miguel>         do_something();
Miguel>     } /* etc. etc.*/

Miguel> is tedious, wasteful and error-prone.  An exception-handling mechanism
Miguel> should be the exact opposite of this, and syntactically as simple as
Miguel> possible.  I doubt if requiring a try{} block is the right approach.

The ...

read more »



Sun, 01 Jun 1997 00:18:42 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)

Quote:


>         Hmm.. I feel that the fact that there are probably 50 C++ programmers
> for every objective C programmer an indication that C++ is 50 times better.
> The fact that objective C is such a failure is because of inherent
> problems in it's design.

>  < The above has several invisible smileys >

And so it follows that since there are 50 times more Windows users than  
NeXTStep users, Windows is 50 times better.  :-)

The above is obviously not true for anyone who has used both Windows and  
NeXTStep.  Just because something is popular, doesn't mean it is the best.  
Actually, the opposite seems to be true.  When a tool is targeted to such a  
large number of people, the usefulness of the tool for each person drops,  
because different people have different ideas of what is needed in this tool.

Any language is a combination of various tradeoffs.  C++ is convoluted because  
it had to use the same syntax as C, in order to maintain compatibility with C  
(The whole reason why C++ is so popular.  Why reinvent the wheel?)  IMHO,  
Eiffel takes a better direction.  It doesn't try to be source code compatible  
with C, but instead is designed to be a good OO language.  Then it provides a  
great interface to other languages, so wrappers can be made for legacy C code.  
Eiffel also compiles to C, and even creates a makefile for you.

So I think that the backward compatibility issue is not enough to warrant using  
an omnibus language such as C++.

Quote:
> : Again, in my opinion, this section reinforces my opinion that the _reason_
> : that C++ became as complex as it now is, was because Bjarne continually
> : added features because people said `C++ is no good because you can't <XXX>
> : with it.'  And especially, that he tried to make sure that you could
> : write code that would run as fast as the equivalent C code.

> : For me, that section explained _why_ C++ is too complex.

Exactly.

Quote:
>         Too complex for what?  I don't know, but the reason I like C++
> is because it often runs as fast as equivalent C code, and is good for
> many purposes.  But I guess I'm just foolish enough to want a
> powerful, fast language.

Check out Eiffel.  It's almost as fast as C, and has many more OO features  
built in.  These help to produce better designs, something that pays off more  
in the long run than slightly faster code to start with.  It also has the most  
elegant syntax I have ever seen.

Regards,
Wolfgang Ziller



Sun, 01 Jun 1997 07:36:34 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)

Quote:



>>Miguel> But I haven't yet revealed the real, fundamental and unnegotiable
>>Miguel> reason why I don't like C++:  name mangling.

You must be confused, name mangling isn't apart of C++.  This
statement is like saying, I hate C because of assembly langauge.  It
may be true that most compilers transform C into assmbly, but why
should that upset you, don't look at it!  If you don't like name
mangling, don't look at mangled names!  Nobody is forcing you, are
they?  If they are complain to your vendor!

Are you sure the real issue is lack of binary interopability between
various vendors compilers?  If that is it, just come out and give us
the real reason.

Quote:
>I fear that the issue of name mangling is much like that of the (lack
>of a) standard class library.  It is not a language issue per se, but
>leaving it unspecified and implementation dependent does more harm
>than good.  Either prescribe exactly how names should be
>"decdorated", or proscribe it.  Preferrably the latter.

You show an amazing lack of understanding of the issues surrounding
the implementation of any high level language, as well as what is
traditionally acceptable to standardize in a langauge standard.

For example, do you like the C standard, or the Pascal standard, or
the fortran standard?  If you do, do you realize that those standards
fail to exactly specify object layout, calling conventions, if
parameters can be passed in registers, etc.

In the exact same way, the C++ standard will fail to specify the same
sort of nagging little details surrounding the implementation of C++
on any real machine.  This isn't a failing of the standard, but rather
a lack of understanding on your part.  There is a place for binary
standards.  And binary standards do exist, even for C++.  For example,
Sun has a binary standard for C++ that they are pushing.  It `works'
on (specifies) one, maybe two platforms.  From my perspective, this is
not enough.

Time will tell if people want a binary standard for C++ or not.

If they do, it will be created and they will follow it...



Sun, 01 Jun 1997 12:21:33 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)

Quote:

>Comments on Miguel Carrasquer's comments on Stroustrup:

>Miguel> [I read Bjarne Stroustrup's article in defence of his "baby"
>Miguel> with great interest.  I have never said C++ "sucks", but in
>Miguel> my own small way I have occasionally dropped some words of
>Miguel> innuendo against the language.

>...such as the innuendo in the very first line of this message.

If you mean the word "baby", that wasn't meant as innuendo, really.
If someone stands up in a public forum to defend his brain-child,
it shows that the author cares about the language.  Which implies
good things about how it was designed...

Quote:
>Lack of a good standard library is Bjarne's biggest regret in the
>design of C++.  [..]
>Perhaps a more interesting question: how long would it have been worth
>delaying C++ to make a standard library available?

Good question.  And it is indeed better not to have a library at all
than a buggy, deficient or inadequate one (I don't think a clone
of the Smalltalk library would have been adequate for C++).

Quote:
>Miguel> I don't know much about the proposed "runtime type identification"
>Miguel> proposals, but the name would seem to implicate that Smalltalk-
>Miguel> like runtime flexibility is going to be retrofitted in the language
>Miguel> after all.

>More innuendo.  First you object because the language doesn't do
>what you want, then you object because it does.

How can I object to something I don't know about?  I think
retrofitting (e.g. C++ function prototypes in ANSI C) can be
perfectly allright.  Within reason, and if done well.

Quote:
>Miguel> of syntactic sugar.  Garbage collection would also be nice to have,
>Miguel>if only because it would eliminate the need for destructors (along with
>Miguel> their weird notation).

>More innuendo.  Why do people get so hung up over syntax?  If it looks
>weird, that means you haven't used it enough to understand it.

I haven't used it enough to _get used to it_.  People can get used
to any syntax (e.g. Cobol, and I'm really not insinuating anything...).  

Quote:
>The original exception handling proposal did not use an extra `try' keyword.
>It met with fierce resistance.  People wanted to be able to see at the
>beginning of a section code that an exception might be caught from that code.

>Miguel> And passing arbitrary data to an exception handler is nice, but not
>Miguel> essential.  Now everybody will start writing their own exception
classes...
>Miguel> Yet more complexity and overhead!

>In other words, the ability to pass data to an exception handler
>is a bad idea because it is useful.  How's that again?

Sorry, I was not separating issues clearly here.  Exception handling
should be easy to understand and use from the user (programmer)'s
perspective.  Implementation is another issue.  If I compare C++
exception handling with CLU, Chill and Ada (all of which use the
`termination model' as opposed to the `resumption model' of PL/I),
then Ada and Chill do not associate additional data with exceptions,
CLU and C++ do.  CLU and Chill do not propagate exceptions, as do
Ada and C++.  C++ in both cases has chosen the more difficult to
implement model.  One can defend this choice if it allows a clearer,
more elegant model of exception handling to be presented to the
user of the language.  

I must say that I haven't had the opportunity to use exception-handling
in any real situation in any language.  I'm not sure I have seen the
One True model of exception handling yet.  Of the syntactic mechanisms
proposed, I think CLU and Chill seem to be the most stylized.  I don't
know how it is to work with them in practice.  I'm glad that C++
allows the same model to be used (without enforcing it), i.e.
exception specifications attached to functions.  What I like about
this is that it builds on the function call model:  function f
returns a value of type t, OR it throws such-and-such exceptions.
Within such a model, imposing restrictions on the data associated
with an exception makes perfect sense: there are also restrictions
on what a function may return.  If that makes the model conceptually
easier to understand, and also easier to implement, it may be worth
losing some of the additional power/flexibility of the current
implementation.

Quote:
>Miguel> But I haven't yet revealed the real, fundamental and unnegotiable
>Miguel> reason why I don't like C++:  name mangling.

>...which, of course, is not an aspect of C++ at all but rather of particular
>implementations of it.

Yes, but sanctioned (if not specified) by the ARM.  I was shocked
at first to learn that this was _not_ a Microsoft "extension" to
the language.

I fear that the issue of name mangling is much like that of the
(lack of a) standard class library.  It is not a language issue
per se, but leaving it unspecified and implementation dependent
does more harm than good.  Either prescribe exactly how names
should be "decdorated", or proscribe it.  Preferrably the latter.

--
Miguel Carrasquer         ____________________  ~~~
Amsterdam                [                  ||]~  



Sun, 01 Jun 1997 09:28:42 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)

Quote:


>: Too complex for the 'average' (your words) teacher to teach effectively.  
>: If the language cannot be passed on in a manner which causes the majority
>: of the students to use it effectively and to its full potential, then
>: perhaps it could be considered too complex.

     C++ is more complex than it needs to be for what it does.  The
primary reasons for this are:

     - backwards compatibility with C, primarily in the area of declaration
       syntax and defaults,

     - backwards compatibility with dumb linkers, which yields
        name mangling, manual (or inefficient) template instantiation,
        wierd static initialization rules, and bad diagnostics,

     - backwards compatibility with previous versions of C++, which
        yields a heritage of class libraries that don't use templates,
        have type conflicts when used together, or insist everything
        be descended from some "Object" class,

     - backwards compatibility with the ".h" file concept of interface
        specification, which leads to wierd rules required to make
        various things get instantiated exactly once, and which
        yields interface files which contain both interface and
        some internals of a class, and

     - backwards compatibility with C pointer semantics, which
        yields wierd procedure call rules for an OOP language and
        wierd semantics for the relationship between pointers
        and references.

Yes, there are techniques for "programming around" all these language
problems.  But that's partly why the language is hard to learn; there's
a huge "{*filter*}tradition" one has to absorb to use it.  I'm not talking about
OOP concepts here; this is strictly about the problems of C++ due to
its historical baggage.

     I realize that if it didn't "look like C", people wouldn't use it,
despite the fact it's probably easier to learn Modula 3 (and definitely
easier to learn Smalltalk) than C++.

     Actually, we now have enough experience with C++ (except for
exceptions and iterators, which are too new) to have a fairly
good idea what worked and what didn't.  It's time to design the
next language, which could be substantially simpler, provided
that some backwards compatibility is dropped.  The next language
should probably "look like C++", but not be directly compatible;
mechanical conversion from C or C++ to the next language should be
provided instead.  This lets us dump the garbage and keep the good stuff.

                                        John Nagle



Sun, 01 Jun 1997 14:17:43 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)

:  ...
: Too complex for the 'average' (your words) teacher to teach effectively.  
: If the language cannot be passed on in a manner which causes the majority
: of the students to use it effectively and to its full potential, then
: perhaps it could be considered too complex.

Hmmmm.  So if a majority of farmers can't make a living from farming, then
everybody should give it up?  Who needs to eat, anyway!

Perhaps not all who wish to be programmers in the new world will be able
to just because they want to.

- Lenny Gray -



Sun, 01 Jun 1997 12:34:25 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)


Quote:

> [ Bjarne Stroustrop writes: ]
> > Personally, I have found many stimulating ideas in Ada, Algol68,
> > CLOS, Eiffel, ML, Modula-*, Smalltalk, Simula, etc. and in code
> > written in those languages.

> So have I.  But in all honesty, in the few 10's of thousands of lines of
> C++ code I've read, and the 2 books and half a dozen papers, I've found
> nothing that hasn't been better addressed in one or more of these
> other languages.  But that's just my personal opinion.

I don't quite see the significance of this observation; using all your
favorite features from various different languages isn't an option in
real life, while using C++ is.  Does any one of these other languages
address *every* issue better than C++?

-David

--

  Ultracomputer Lab         |      GAIM Project
  715 B'way, NYC 10003      |      212.998.3346



Sun, 01 Jun 1997 03:46:04 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)
<<The simple C rule that
<<calling a function will not modify your variables, unless you pass an
<<address (or your variable is an array, of course) is subverted, a
<<problem that will make code maintenanace more difficult and
<<error-prone. Also, new notations have to be introduced (::, ::*, .*, ...)

<I have heard this criticism often, yet people who have had to maintain large
<bodies of C code and then of C++ code generally report that the C++ code is
<easier to maintain. Maybe it has to do with how well the code is written --
<in which case I would rather choose a language based on the best it can do
<rather than the worst.

I mostly agree with this defense of C++, but the point about the C++ subversion
of C's guarantee about not mucking with your parameters, is well taken, and is
(IMHO) a serious defect. I try to be a fanatic about not modifying parameters
anyway, in C; but at least when you create a function that does modify a
parameter, the client is obligated by the compiler to provide an address-of
operator, which clearly documents the potential modification. When passing
arrays, the '&' is still permissible (thank you, ANSI!) and I make it a
point to use it to drive home the fact that, yes, this array is going to
change before the function returns. C++ references completely yank the
rug out. x(a) might modify a. Reading new code is suddenly an exercise in
remembering every relevant function prototype, or having a nifty tool that
paints modifiable parameters in a different color. (Hint to C++ editor writers:
I have not seen this feature yet, and I want it, and would cheerfully pay
an extra $50 for it, if I were maintaining thousands of lines of someone
else's C++.)

That C++ is easier to maintain than C follows from a number of things -
insistance on prototyping probably being the biggest, but certain aspects
of classes help make code more understandable overall. References subvert
many of the gains, though. Was it really worth it?

--
From the ignominious last words file:
 "Portable? Oh. Why does it have to be portable?"



Sun, 01 Jun 1997 21:37:11 GMT  
 Bjarne's defence of C++ (Was: Re: Widespread C++ Competency Gap?)

|> That said, I agree that GC would be nice to have, if there were a
|> way to do it without giving up anything else.  The best bet so far
|> seems to be one of the conservative collectors.  I am personally
|> not fond of conservative collectors, because they are inefficient at
|> reclaiming memory compared with copying collectors -- but if you
|> like them, then by all means use them.

On the first hand, all correct garbage collectors are conservative, if
garbage is defined to be any resource which will not be used, since
garbage can be reachable.  That is, garbage collectors attempt to
identify the resources reachable by the program and throw away all the
rest; it is often the case that a resource is reachable but still
garbage, but proving this is equivalent to the halting problem.

"conservative" garbage collectors have a further problem: identifying
which resources are reachable.  Showing whether a resource is
reachable can also be equivalent to the halting problem in a C-like
language and implementation.  For example, pointers kept in pieces
which need to be put together via bit ops like xor will not be found
by most conservative garbage collectors.

That said, there is a large subset of C and C++ which can be used with
a conservative garbage collector with little overhead caused by the
language being C or C++.  For more info, I'd suggest the garbage
collection page
http://www.lpac.qmw.ac.uk/SEL-HPC/Articles/GeneratedHtml/comp.gc.html
or Paul Wilson's work on garbage collection avilable via hisOOPS page
http://www.cs.utexes.edu/oops/ or snarfing the Boehm-Weiser collector
from http://www.cs.colorado.edu/homes/zorn/public_html/Malloc.html.

David



Mon, 02 Jun 1997 05:10:31 GMT  
 
 [ 100 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7]

 Relevant Pages 

1. Widespread C++ Competency Gap?

2. Widespread C++ Competency Gap?

3. What's Real-Time? (was Re: Widespread C++ Competency Gap?)

4. Real-time GC (ws Re: Widespread C++ Competency Gap?)

5. Why I am (core) dumping C++ for OOCOBOL

6. C++ question for Smalltalk/C++ programmers

7. NYC C++ mtg 9/7/95 Building a C++ Class Library

8. C++ or (Smalltalk and C++)?

9. to CS: or not to CS: in F-PC assembler

10. Cellular automata benchmarks: Java vs C++ vs Java vs C++

11. Request advice about C++ and Visual C++ topics

12. Migrating from UNIX C++ to MVS C++

 

 
Powered by phpBB® Forum Software