smayo@iii1.iii.net (Scott Mayo) wrote in comp.lang.c++,comp.lang.c,comp.object,comp.lang.misc,comp.std.c++
><<The simple C rule 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++.)
>
If you can guauge this soley from say "const" then you can do this in
XEmacs and FSF Emacs today. However, you can only trap declarations.
Yes this is a good idea and I think it would be cool if you can take
an identifier and indicate graphcally whether it's modifyable or not.

I would like to know what the AT&T stars use.

Are they using BAW's cc-mode under Emacs?
--
           "Oh no, actually darling I don't have time for games."
            (PGP key: send email with Subject: request pgp key)
                    (ASCII for text only messages)

>Once OS's become clearly written in C++ in a C++ centric manner...

Why should OS's be "C++ centric"?  People should use the right tool
for the job.  Operating systems shouldn't be tied to any particular
programming language.  There is a growing set of methods for
'cross-language' calling, including things like CORBA, DCE, and the
work of ISO/IEC JTC1/SC22/WG11.

    dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors.
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

jimad@microsoft.com (Jim Adcock) writes:
>What we see emerging are "standard object models", calling conventions,
>etc, for each particular operating system, such that compilers, libraries,
>apps, etc on that particular operating system can communicate with each
>other.

Unfortunately this can't happen on Microsoft platforms, it appears, since
Microsoft has patented their object layout.  (Jim, I certainly know you
don't set policy for Microsoft, but since you bring up the issue...)

To view this patent, entitled "Method and system for implementing virtual
functions and virtual base classes and setting a this pointer for an
object-oriented programming language", number 5,297,284, point your
Web browser at

http://www.town.hall.org/Archives/patent/data1/05297/05297284

Read it and weep.  Committee members, don't you wish *you* had this much
gall?

In essence, Microsoft patented an improvement on the "thunks" method
described in the ARM -- an improvement that has been independently
re-invented by many folks, including myself and Per Bothner of Cygnus,
before the patent was published, but may be OK anyway if there wasn't
a publication describing it.  It would appear that any other compiler
vendor implementing objects with multiple inheritance or with virtual
base classes in a compatible way would infringe the patent.  They could
license the patent, but this would rule out a compatible g++ port.

It would be legal for Microsoft to refuse to license this patent
altogether, meaning no legal compiler could be compatible.  Aren't
software patents fun?  Any dominant player in any market can make it
illegal for competitors to be compatible.
--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

In article <1994Dec16.072829.1194@mole-end.matawan.nj.us>,
 <mat@mole-end.matawan.nj.us> wrote:
>In article <D0pJ8w.438@research.att.com>, ark@research.att.com (Andrew Koenig) writes:
>
>>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
>> Luke> experienced people can fail to learn.  And the language designer
>> Luke> admits this. 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?
>
>I think I've found a More Serious Problem.
>
>Engineering undergraduates are `taught' a theory based on a system of
>equations which few fully master.  It involves several mathematical
>techniques which are known to give even skilled practitioners difficulty.
>

*GOSH*
Funny to think that I am contributing to a C++ newsgroup, in a thread with
Bjarne Stroustrup himself in it ( classes ... erm ... they're kinda like
structures, aren't they? :), but the applied maths stuff I'm supposed
to know more about so I take ths opportunity to ask...

>I am referring to (Clerk) Maxwell's equations.  They are so clumsy

I thought they were neat.
Lots of clever folk have said they are neat.

 that
>they must be stated twice!  (Differential AND integral form.)

Huh?  Do they have to be stated twice?
Huh?  Do they have to be stated twice?

 While
>substituting vector calculus has simplified things somewhat over the
>old quarternion-based math,

Oh.  I did not thnk about quaternion-based maths.  That's quite horrible.
I must go and lie down for a bit :-)

 we should be frightened that so few manage
>to master the material rigorously.

I think lots of people master it fairly well each year.  It's heartening in
a Schadenfreude sort of sense if you say that others have difficulties as I
do.

  But the problem isn't the students,
>it's the material.

Ah well, there is a lot of this about.


>
>Heaviside transforms, Operational Calculus, Bessel Functions, Legendre
>Polynomials, and Fourier's heat equations have all been invoked in the
>ill-advised attempt to make these equations useful for ordinary mortals.

*sigh* Surely I don't need all these techniques to understand four simple
 PDE's that elegantly unify the electromagnetic and the mangnetic fields
 due to moving charge?

>None has succeeded, except in a few incomplete, inconsequential special
>cases.   And to make matters worse, Maxwell's equations aren't even
>complete!

Huh?

 They need not one but two continuity equations before they
>can be used as a mathematical system.
>
>As if that weren't enough, attempting to apply them in a non-inertial
>frame of reference produces results which contradict common sense,
>requiring either the abandonment of the addition of velocities or the
>constancy of time!

I thought that that was part of why they are neat.  Am I being
`trolled' ?

>
>Anyone who teaches or uses the so-called `equations' is an irresponsible,
>reckless moron.

Oh yeah, I agree with you there.  But everyone knows that many lecturers are
morons :-)  <---------- enters into spirit at last!


>[Note for the humor-impaired: Clerk Maxwell's equations are the foundation
                 ^
            Me ME  MEEEE

> of classical electromagnetics, and do indeed predict relativistic effects,
> if only we could have seen them.  Maxwell demonstrated E-M propagation
> mathematically; H. Hertz created the physical demonstrations which proved
> them.]
>--
/**************************************************************************/
/*      Pessimism of the Intellect, optimism of the Will     -- A Gramsci */
/*       Bill = William Weston = wweston@coventry.ac.uk    PGP on request */
/**************************************************************************/

In article <D0s1Fu.FJI@inter.NL.net> mcv@inter.NL.net (Miguel Carrasquer) writes:
|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.

I agree that leaving name mangling, and other linking specifications
unstandardized does more harm than good -- however -- these issues have
*never* been one of language specification and standardization.  Rather,
these have always been issues of operating system design and specification.
What we see emerging are "standard object models", calling conventions,
etc, for each particular operating system, such that compilers, libraries,
apps, etc on that particular operating system can communicate with each
other.  Once OS's become clearly written in C++ in a C++ centric manner, rather
than written in C, or written in C++ such that C code can call OS routines,
then this distinction will become clear.

Lobby your target OS vendor, not the C++ committee.

In article <3d6t9g$lje@cc_sysk.coventry.ac.uk> wweston@cck.coventry.ac.uk (WILLIAM WESTON) writes:
> In article <1994Dec16.072829.1194@mole-end.matawan.nj.us>,
>  <mat@mole-end.matawan.nj.us> wrote:

> >[Note for the humor-impaired: Clerk Maxwell's equations are the foundation
>                  ^
>             Me ME  MEEEE

But of course! -- but on the other hand, your posting clearly
shows that you are not humour-impaired.
      ^
      |
  note that the spelling changes
  when one crosses the Atlantic
--
    --Andrew Koenig
      ark@research.att.com

In article <D0rBz6.CMB@research.att.com>,
Andrew Koenig <ark@research.att.com> wrote:
>Every C++ compiler I know checks function return types in all the
>circumstances that K&R C does.  Most C compilers will miss
>
> extern int foo();
>
>in one translation unit and
>
> long foo() { /* ... */ }
>
>in another for exactly the same reason that C++ compilers will miss it,
>namely that the linkers aren't smart enough.  If you are implementing C++
>and have the luxury of implementing the linker as well, then of course you
>should make the linker check function return types.
>
>This is scarcely relevant to the C++ language.  It is purely an
>implementation issue, and some C++ compilers do enforce return type
>consistency.

For C++ this is currently true.  However, this can and has been made a
language issue elsewhere.  Some languages require that these sorts of
checks across compilation units be done automatically to permit safer
construction of large programs.  Detecting and fixing bugs resulting from
external interface mis-matches can be quite painful.  Avoiding these
problems was a major design goal of the Ada language.

In Ada, each compilation unit must identify external dependencies (the
WITH clause), and the compiler (not linker) must check that each external
reference follows the usage constraints specified for that external
object.  This includes not only return type checks, but also checks the
number, types, and names of parameters.  It is a little more work for the
compiler, but makes life much easier for programming in the large.

[Not meaning to start a language war.  Just pointing out how this problem
has been handled better by another language.]

-Jon
--
|Jon L. Spear (spear@cs.nps.navy.mil) : Member, Team-Ada.  You can't be too|
|Dept of Comp Sci, Code CS/Sj, x2830  : rich or have a .sig file that's too|

Thant Tessman (thant@disney.com) wrote:
|>
|> When all you have is a hammer, every screw looks like a nail with
|> threads.
|>
|> thant

Peter masquarading as Jesper Kaagaard (etiaseti@inet.uni-c.dk) wrote:
|>
|> Great technical argument, you convinced me. The sublime analysis in the
|> prceeding really show the thoughtfull nature of the author.

and followed up with:
|>
|> just to elaborate a little more, I think that Tessman's post is a good
|> example of the innuendo that gets posted against C++.
|>
|> --- peter
|>

I think that Thant's point is fairly correct. Most programmers learn
to solve problems in a particular language. When they move to another
language this knowledge does not necessarily transfer. The problem
is they want to solve the same problem the same way they did with
the old language.

Now it may be that their old language provided a better solution but
often the new language provides a better (or at least equally good)
solution but which is different. You need to keep in mind the problem
you want to solve not how you think you should be able to solve it.

I have seen repeated cases of people who have a workable solution to
a problem look at another language, determine that the solution they
already have won't work and then decide that the language they are
using is the best one for the job; never realizing that the other
language would have worked better to solve the problem but with
a different solution.

Smalltalk solutions look bad in C++ and C++ solutions look bad in
Lisp. This is no basis to conclude that one language is better
than the other, only that they are different. To compare langauges
you have to go beyond language features to get anything meaningful.

Robb Nebbe

In article <238f.smail.smayo@iii.net> smayo@iii1.iii.net (Scott Mayo) writes:

> 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.

Except that that `guarantee' in C is no more than a formality because
of the automatic conversion of arrays to pointers.  So...

 main()
 {
  int x[100];

  f(x);

  /* ... */
 }

Guarantee or no, the call to f(x) is capable of modifying the elements of x.
Moreover, you cannot simply make that fact explicit by calling f(&x)
instead; doing so will cause a type error in any fully declared
context in which f(x) is legal.
--
    --Andrew Koenig
      ark@research.att.com

Rachel Polanskis (grove@zeta.org.au) wrote:
>luke@research.canon.oz.au (Luke Kendall) writes:
[...]
>>...  Interestingly, the turning point for me was the highly-educational
>>internal `C++ Coding Standard' document that was prepared in-house. ...
>>The document was written by highly experienced and intelligent C++ users,
>>who were also firm advocates of C++, as a matter of interest.

>Since a lot of us are still finding our way through this and, as there is
>lot of mickey mouse code around teaching us how to code seriously, do you
>think your colleagues would share the 'C++ Coding Standard' document with
>us on the net?

I can't offer the mentioned in-house document, but something that will make
you feel sorry for anybody who has to maintain other people's C++ code, too.
Check out

 http://info.desy.de/user/projects/C++.html

under 'Getting Start(l)ed/Critique'.

When I started with C++ ~3 years ago, I knew C pretty well. I read
Lipman's C++ Primer (2nd. ed.), and Copliens' (excellent) 'Advanced
Styles and Idioms' when I wanted to know more. I was about to dive into
C++ full-time. At the same time I came across the above documents, I also
learned Smalltalk and after that Objective-C. That was the time the
lightning struck me what OOP is _really_ all about; I haven't written a
single line of pure C++ since then. I'm 24 (8 years programming exp.),
and thinking about large C++ project (partially) written by people who
don't even understand proper modular design makes me want to change my
job future. Ask any random C++ programmer the trick question what
LAN/MAN/WAN network design and large-scale OOP have in common.
Most of them don't even understand the question.

Regards,

 Holger
--
Holger Hoffst   tte // [EMail sendTo: @"hoff@darmstadt.gmd.de" NeXTMail: YES];

In article <D0pJ8w.438@research.att.com>,
Andrew Koenig <ark@research.att.com> wrote:
>A few comments on Luke Kendall's comments on Bjarne's article.
>...
>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.

It would be nice if we had a crisp & testable definition of `proficient' in
this context.

(I also teach C++ to C programmers.  I just got back from a week in Houston
doing just that.  I would not characterize my students as now suddenly being
`proficient' C++ programmers, but I believe that I have given them the basic
understandings that they will need to _become_ proficient, with time and
practice.)

>It takes about as long to learn C++ as it does to learn to drive a car.

I suppose that in a sense this is true.  I can teach a 14-year-old how to
drive a car in about 2 hours.  Just don't ask me to sell him a collision
insurance policy after just those 2-hours of instruction. (1/2 :-)

>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.

Quite true.  The converse is also true, i.e. claming that it is _not_ too
complex (without specifying some context) is not particularly informative.

>I don't think C++ compilers are any more buggy than any other widely
>distributed commercial software...

This is just not true, in my opinion.  (Note that my opinion is based upon
my actual experience as a tester of C++ compilers.)

>...  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.

Likewise.

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

I endorse that sentiment wholeheartedly.

Note:  Follow-ups directed only to {comp.lang.c++,comp.lang.c,comp.object,
comp.lang.misc} since this thread doesn't bear directly upon the forthcoming
C++ standard.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -

Miguel Carrasquer (mcv@inter.NL.net) wrote:

> No, I see the point of "virtual" (and "inner").  However, in
> Smalltalk, member functions are, one could say, _always_ virtual.
> A special mechanism ("super") must be used to access methods
> _up_ the object hierarchy.  The price you pay is that all methods
> must be looked up first, instead of called directly.   This being
> said, the Smalltalk equivalent of a "pure virtual function" does
> exist in the form of the "subclassResponsibility" error.

I may have misconstrued the extent of your assertion: "But the whole
concept is philosophically "backwards". However they are done by its
successors, I don't think SIMULA got things back to front.

However, I would question your earlier statement that "OOP, ... is
supposed to be all about code reusability and quick & easy application
development". Actually, in the first instance, OOP is all about
identifying and exploiting the inherent conceptual and mechanical
structure in complex systems in order to describe them accurately and
implement them correctly. Reuse and rapid development are (or, rather, may
be) the by-products of the problem factorisation and superior structure
resulting from this approach. Reuse has been over-hyped in certain
quarters and, as an a priori objective, can require much far-sighted
perception for its effective attainment.


> >Many who claim to have a solid appreciation of OOP could do well to study
> >closely Nygaard and Dahl's paper.

> I haven't read it, but _SIMULA_BEGIN_ by the same authors (plus
> Birtwistle and Myhrhaug) is excellent.

Some loved that book and some hated it. I guess the latter are those who
never really grasped what this is all about.

Someone suggested that I repeat the reference (which I have already posted
on several occasions) to the Nyggard & Dahl paper which describes how the
concepts now known as object orientation crystallised.

      "The  Development of the SIMULA Languages", K.  Nygaard  &  O.-J.
      Dahl, in History of Programming Languages, Academic Press, 1981.

 There is another interesting new paper on the history of SIMULA:

      "Compiling  SIMULA: a Historical Study of Technological Genesis",
      Jan Rune Holmevik, IEEE Annals of the History of Computing,  Vol.
      16, No. 4, 1994.

I keep mentioning SIMULA because it was at the heart of all of this and
because it probably presents a much less opinionated picture of the
important concepts than some of its successors. Moreover, in some respects
it is still ahead of the game. For instance, it is with wry amusement that
I see SIMULA's autonomous object features being revived in the contexts of
simulation and parallelism.

Cheers....Ron

------------------------------------------------------------------------
  Ron Kerr, Computing Service, Newcastle University, NE1 7RU, England.
 Tel. +44 191 222 8187       Fax. +44 191 222 8765  (NOTE new area code)
------------------------------------------------------------------------

mrs@kithrup.com (Mike Stump) writes:
>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!

OK, Mike.  You're a vendor.  The setup you provide forces users to
look at mangled names whenever they have undefined symbols, at least
when the default configuration (where collect2 + native Unix linker
is used).

Followups to comp.lang.c++ only.

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

Binary standards will be hard, when we have, for instance, Microsoft
*patenting* the way they do object layout for multiple inheritance.


--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

>When all you have is a hammer, every screw looks like a nail with
>threads.

And when all you have is a screwdriver, you end up screwing
everything...
    dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors.
-- "A good plan violently executed -NOW- is better than a perfect plan
--  next week"                                      George Patton
-- "Any damn fool can write a plan.  It's the execution that gets you
--  all screwed up"                              James Hollingsworth
-------------------------------------------------------------------------

luke@research.canon.oz.au (Luke Kendall) writes:

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

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

>...  Interestingly, the turning point for me was the highly-educational
>internal `C++ Coding Standard' document that was prepared in-house. ...
>The document was written by highly experienced and intelligent C++ users,
>who were also firm advocates of C++, as a matter of interest.

Since a lot of us are still finding our way through this and, as there is
lot of mickey mouse code around teaching us how to code seriously, do you
think your colleagues would share the 'C++ Coding Standard' document with
us on the net?

bye
Rachel

In article <D0pJ8w.438@research.att.com>, ark@research.att.com (Andrew Koenig) writes:

>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
> Luke> experienced people can fail to learn.  And the language designer
> Luke> admits this. 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?

I think I've found a More Serious Problem.

Engineering undergraduates are `taught' a theory based on a system of
equations which few fully master.  It involves several mathematical
techniques which are known to give even skilled practitioners difficulty.

I am referring to (Clerk) Maxwell's equations.  They are so clumsy that
they must be stated twice!  (Differential AND integral form.)  While
substituting vector calculus has simplified things somewhat over the
old quarternion-based math, we should be frightened that so few manage
to master the material rigorously.  But the problem isn't the students,
it's the material.

Heaviside transforms, Operational Calculus, Bessel Functions, Legendre
Polynomials, and Fourier's heat equations have all been invoked in the
ill-advised attempt to make these equations useful for ordinary mortals.
None has succeeded, except in a few incomplete, inconsequential special
cases.   And to make matters worse, Maxwell's equations aren't even
complete!  They need not one but two continuity equations before they
can be used as a mathematical system.

As if that weren't enough, attempting to apply them in a non-inertial
frame of reference produces results which contradict common sense,
requiring either the abandonment of the addition of velocities or the
constancy of time!

Anyone who teaches or uses the so-called `equations' is an irresponsible,
reckless moron.

[Note for the humor-impaired: Clerk Maxwell's equations are the foundation
 of classical electromagnetics, and do indeed predict relativistic effects,
 if only we could have seen them.  Maxwell demonstrated E-M propagation
 mathematically; H. Hertz created the physical demonstrations which proved
 them.]
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
 (Training and consulting in C, C++, UNIX, etc.)

Thant Tessman (thant@disney.com) wrote:

: In article <D0pJ8w.438@research.att.com>, ark@research.att.com writes:

: > [...]  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.  [...]

: When all you have is a hammer, every screw looks like a nail with
: threads.

: thant

Great technical argument, you convinced me. The sublime analysis in the
prceeding really show the thoughtfull nature of the author.

--- peter (no matter what the from field says)

Miguel Carrasquer (mcv@inter.NL.net) wrote:


> 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

You seem to have missed the point, regarding the role of virtual functions
(in SIMULA, at least). These were introduced in order to support the
process of abstraction in which notions could be not only introduced but
utilised freely at one level of abstraction, deferring their various
implementations to the subsequent, and perhaps not yet foreseen,
realisations of the abstraction. For example, sorting algorithms depend
upon the notion of ranking between the items but the mechanics of ranking
depend upon the nature (numerical, textual, etc.) of the items being
sorted. By introducing ranking as a virtual function a complete but
abstract sorting mechanism can be constructed with no knowledge at all of
the various types of items this may subsequently be used to sort.

The crystalisation of the "virtual" concept is recounted in Nygaard &
Dahl's paper "The History of the SIMULA Languages" - "We also needed to
group together common process properties in such a way that they could be
applied **later**, in a variety of different situations not necessarily
known in advance."

Many who claim to have a solid appreciation of OOP could do well to study
closely Nygaard and Dahl's paper.

Cheers....Ron

In article <3cs1o3$p74@whitbeck.ncl.ac.uk>, R. Kerr <R.Kerr@ncl.ac.uk> wrote:
>Miguel Carrasquer (mcv@inter.NL.net) wrote:
>
>> The flexibility [of e.g. Smalltalk] 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
>
>You seem to have missed the point, regarding the role of virtual functions
>(in SIMULA, at least). These were introduced in order to support the
>process of abstraction in which notions could be not only introduced but
>utilised freely at one level of abstraction, deferring their various
>implementations to the subsequent, and perhaps not yet foreseen,
>realisations of the abstraction.

No, I see the point of "virtual" (and "inner").  However, in
Smalltalk, member functions are, one could say, _always_ virtual.
A special mechanism ("super") must be used to access methods
_up_ the object hierarchy.  The price you pay is that all methods
must be looked up first, instead of called directly.   This being
said, the Smalltalk equivalent of a "pure virtual function" does
exist in the form of the "subclassResponsibility" error.

>Many who claim to have a solid appreciation of OOP could do well to study
>closely Nygaard and Dahl's paper.

I haven't read it, but _SIMULA_BEGIN_ by the same authors (plus
Birtwistle and Myhrhaug) is excellent.

--
Miguel Carrasquer         ____________________  ~~~
Amsterdam                [                  ||]~
mcv@inter.NL.net         ce .sig n'est pas une .cig

In article <3cqir3$6le@godzilla.zeta.org.au>, grove@zeta.org.au (Rachel Polanskis) writes:
|> >...  Interestingly, the turning point for me was the highly-educational
|> >internal `C++ Coding Standard' document that was prepared in-house. ...
|> >The document was written by highly experienced and intelligent C++ users,
|> >who were also firm advocates of C++, as a matter of interest.
|>
|> Since a lot of us are still finding our way through this and, as there is
|> lot of mickey mouse code around teaching us how to code seriously, do you
|> think your colleagues would share the 'C++ Coding Standard' document with
|> us on the net?

This may not be that easy.  If the one in question is the one by
Logothetis and Wilkinson, it is marked "ATT Proprietary".

How would we have to go to get permission to remove the proprietary
status?  Do we *want* to bother VP's with this sort of thing?

--
swf@elsegundoca.attgis.com  sarima@netcom.com

The peace of God be with you.

Jesper Kaagaard (etiaseti@inet.uni-c.dk) wrote:
: Thant Tessman (thant@disney.com) wrote:

: : In article <D0pJ8w.438@research.att.com>, ark@research.att.com writes:

: : When all you have is a hammer, every screw looks like a nail with
: : threads.

: : thant

: Great technical argument, you convinced me. The sublime analysis in the
: prceeding really show the thoughtfull nature of the author.

: --- peter (no matter what the from field says)

just to elaborate a little more, I think that Thassmans post is a good
example of the innuendo that gets posted against C++.

--- peter

Scott Mayo (smayo@iii1.iii.net) says:

> 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.

No it's not, if the program is well enough written so that the
meanings of x, a and calling x(a) are apparent in context.
If you write code which which has unexpected side-effects it's just
bad code, not an inherent problem with the language.

> References subvert many of the gains, though. Was it really worth it?

Oh, most definitely.

--
| Neil Gall                        | Internet:  neilg@hpsqf.sqf.hp.com |
| Hewlett-Packard Ltd              | Phone:     +44 (0)131 331 7112    |
| Queensferry Telecomms Operation  | Fax:       +44 (0)131 331 7488    |
| South Queensferry, Scotland      | HP Telnet: 313-2112               |

Taylor Hutt (thutt@clark.net) wrote:

:  ...
: 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 -

In article <D0oqLz.KAu@research.canon.oz.au>
luke@research.canon.oz.au (Luke Kendall) writes:

> [ 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

--
  David A. Mechner          |      mechner@cs.nyu.edu
  Ultracomputer Lab         |      GAIM Project
  715 B'way, NYC 10003      |      212.998.3346

<<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?

--

In article <D0rBz6.CMB@research.att.com>,
ark@research.att.com (Andrew Koenig) writes:
|> 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

Andrew Koenig (ark@research.att.com) wrote:
: A few comments on Luke Kendall's comments on Bjarne's article.


:  C is hardest to write *and* hardest to use.

Actually, writing in C is not that hard.   Reading others'
code sometimes a lot harder.

John Nagle (nagle@netcom.com) wrote:
:      C++ is more complex than it needs to be for what it does.  The
: primary reasons for this are:

[ backwards compatability with C in various ways... ]

: 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.

In a lot of ways this would be great, but you're facing the same
backwards-compatability/inertia problem that is seen throughout the
computing industry, if not most industries.  16-bit DOS is still going
strong despite the 32 and 64 bit processors we have these days.  I
would have loved to dump all the 16-bit restrictions (64k segments!)
years ago, but it is only now that 32-bit operating systems are becoming
widely accepted (and Windows 95 is supposed to _still_ contain some
16-bit code.)  Backwards compatability reassures most people ("I can
still do everything that I used to do") but tends to produce more
and more complex systems, which ultimately becomes somewhat
counter-productive.

Similarly, the jump to a language which is not backwards compatible
is extremely expensive and unlikly to happen quickly; this cost
could probably be reduced with "mechanical conversion", if that is
possible to implement effectively, but would still be high.  How
many programmers, how many class libraries, how much source code
is invested in C++ (or C, or COBOL, or ...)

However, I'd be very interested in using such a language, but
not until there are a couple of decent compilers and preferably
other programming tools such as debuggers, profilers, class
libraries etc.  The cost to a commercial organisation to produce
these programming tools and then push them out into the market
is substantial.  Any software engineering organisation
considering switching would have to be convinced that they
could absorb the costs of switching and survive financially.
Both the new tools and the language specification would have to
be stable, and retraining would have to be realtively easy.

 Mazz.

[David Chatterton]

|   Garbage collection would not be nice to have.  You can easily implement
|   garbage collection (and many libraries do) but it should _NOT_ be a
|   permanent feature of the language.  Too many of my applications which
|   can take hours to run might then take days.

this thread should be renamed to "Widespread GC Competency Gap".

#<Erik>
--
The check is in the mail.  This won't hurt.  You'll find it on the Web.

In article <nagleD0sEtJ.Ltr@netcom.com> nagle@netcom.com (John Nagle) writes:
>
>     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

 Sure. And the way to do that? CPPFront of course.
And for that to be effective we need C++ to be portable.
And for that we need a Standard.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Miguel Carrasquer (mcv@inter.NL.net) wrote:
: 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.

We now have the Standard Template Library.

: 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.

The language has yet to be set in rock and you are saying a standard
library is too late? It is a bit hard to have one without the other.

: 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.

Unfortunately I have to agree.

: 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.

There are several good class libraries about which are architecture and
compiler independant, and very affordable (some are even free).

: 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.

That's why you spend more time designing. Also adding a new virtual
function is not the only method, there are other idioms that can be used.

: 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.

Unfortunately I don't know enough about Smalltalk, but I think the answer
is no. You will be able to identify the exact type and do safe casts. That
is 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.

Many constructors? I fail to see the problem, nor the need for many
constructors. Constructors provide huge control over the initialisation of
member variables, I would much prefer it this way than any "implicit"
technique.

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

Garbage collection would not be nice to have. You can easily implement
garbage collection (and many libraries do) but it should _NOT_ be a
permanent feature of the language. Too many of my applications which can
take hours to run might then take days.

: 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.

(Extracted from a later paragraph)
: On the other hand, I really wish they hadn't bothered
: with "const" (now was that "char *const" or "char const *" or "const
: char *"?).

For exactly the reason that C++ has supposedly subverted C. I agree that it
is confusing that

const int* a;

is the same as:

int const* a;

otherwise "const" is one of the most useful mechanisms for the compiler to
help you avoid errors.

: Also, new
: notations have to be introduced (::, ::*, .*, ->*, yet another &, etc.).
: The net result is that Objective C code, with its blatant departure
: from C syntax (@ keywords, [method-call]), looks and feels more like
: "normal" C than a complex C++ class implementation.

You sure you are not talking about Pascal? It is very much like C hence it
was used.

: 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.

Why not?

: 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!

: 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.

: 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) {
:     case 'a'...'z', '\n', '@':
:         ....;
:         /* no break; */
:     default: ...
:     }

Gee, C and C++ are so broken. And the no break? What if I wanted to?

: 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 types of parameters are encoded in the function names.

: The encoding scheme discussed in the ARM is not standard: every vendor
: can (and does) implement this in their own way.

Well if bothered to read a few more lines Stroustrup says that, and for
good reason. If you had bothered to read the Design and Evolution of C++
(which you obvious have not even heard of), you would understand why it was
_SUGGESTED_ and why it is _NOT_ standard.

: I thought one of the stated
: objects of C++ was being as compatible as possible with C.

Which it is to a very large extent, certainly in linkage.

: Now it's not
: even compatible with itself.  What happened to (object) code reusability?

Who ever said that we had to obtain object code reusability? Next you are
going to try and tell me you can get that with C? From one C compiler to
another on the same platform?

: Yes, I know, you can export functions as extern "C"... yet another ugly
: language extension.

You obviously know a better way...

: 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.

Crap, many linkers 10 years ago only supported names 8 characters in
length, and they weren't (and for many systems still aren't) easy to
replace. You obviously have no idea why name mangling is needed and what
its goals are. Of course the return type is not encoded in the name, it is
the compilers job to ensure that they are the same, not the linker. In fact
the linker should only ensure that every function that was called is
defined. No more, no less.

: I honestly don't know about linkers on other
: architectures:

Really? So what do you know?

: 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.

But where is the standard for debugging info? Of course that is the same
between compilers, not!

: Just add a
: wrapper around the brain-dead linker, and you're done.  Is that so
: difficult if you're already building a compiler?

You obviously have a lot of spare time to write as much crap as this so why
don't you write one? Of course it has to work for templates, and
mult-methods would be nice... And it can't slow down the compilation
process at all, or interfere with the linking of any existing languages...
And shared library support would be nice too!

: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!!

I rest my case. You have no idea of the real issues behind C++. There is
nothing stopping someone writing such linker support (or an environment)
but I don't see too many about?


David Chatterton     | "A new character has come on the scene (I am sure I did
Comp Sci Department, | not invent him, I did not even want him, though I like
Monash Uni, Clayton, | him, but there he came, walking out of the woods of
Australia, 3168.     | Ithilien): Faramir, the brother of Boromir."
Phone: 03 905 5375   | - in a letter from JRR Tolkien to his son, 4 May 1944.
email: davidc@bruce.cs.monash.edu.au

I think that this debate should stop or continue elsewhere.

The point is that Bjarne Stroustrup designed C++ with ONE major goal :
to make a full featured object oriented language fully compatible with
existing C code.

And I think he has pretty succeeded.

Now, everyone has the choice :

  - full object Smalltalk (and his son, Objective-C),
  - "perfectly" designed Eiffel (to Eiffel be perfect, Meyer must be !),
  - DoD recommended Ada (an Eiffel's friend in perfection),
  - interpreted and flexible Lisp's dialects such as CLOS, CEYX, etc ...
  - exotic languages such as Sather, Self, etc ...
  ....
  - or the "all purpose" hybrid-OOL C++.

And everyone agree (even Bjarne I guess) that Eiffel is a well designed
object language, helpfull to understand object's paradigm. However,
programming languages are a secondary concern when designing software.
Grady Booch's OODA is of more interest in this phase of software developing.

But implementation is a different matter. What most people want, as the C++
success shows, is efficiency. That is, the ability to do high or low-level
things, high-level objects or device drivers, high-level services or low-level
algorithms. And with one knowledge, that is one language and one compiler.

The success of C++ resides in two reasons :

   - a well designed all-purpose OOL (otherwise it will not be used and SOLD),
   - economical reasons (C compatibility).

All the rest is philosophy.

Regards.

In article <D0pJ8w.438@research.att.com>, ark@research.att.com writes:

> [...]  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.  [...]

When all you have is a hammer, every screw looks like a nail with
threads.

thant

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 eighteen 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 believing the traps aren't there.
--
    --Andrew Koenig
      ark@research.att.com

In article <D0oqLz.KAu@research.canon.oz.au>,
Luke Kendall <luke@research.canon.oz.au> wrote:

I would like to add some personal notes to this.

BS you all know, LK is Luke.

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

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

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

I for one would be interested in a paper by the hand of Mr. Stroustrup in
which he describes both. However, we must not let ourself get involved in
a language war that degenerates to 'politics', that is, trying to gain the
advantage by willfully misinterpreting or misrepresenting facts. Therefore,
I wouls also like to see practical evidence of projects done in C++ that
succeeded and that failed, most notably accompanied with the reasons why it
failed. My unsubstantiated guess would be that the failing of projects are
not in the first place due to the choice of implementing language.

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

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

But your experience of the time it takes to become proficient ofcourse
depends on your definition of what proficiency of using a language is.
Since there is no way to compare the two definitions, there also is no
objective way to validate both your statement nor Mr. Stroustrup's state-
ment. For the time being I incline the more pessimistic estimate.

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

I'll add another reason to this. Some 'reasonably clever and experienced
people' just fail to make the psychological transition that is needed to
make things fall into place, that is, the notion that one must think
"inside out". On a more personal note, it took me a year to discover the
concept of object inversion. Once I did, the psychological hurdle was
taken.

Another reason might well be that even 'reasonably clever and experienced
people' are inclined to think that they will be able to grok C++ as quick-
ly as they did other languages. This is a fallacy by design. Everybody can
learn a language through learning it by rote, however, that does not imply
that they understand it. Learning C++ cannot be done from the viewpoint
that it is like any other language. It is, but the difficulty lies in the
object-oriented nature of the ideas on which it is based.

LK>  Another telling point. A language which reasonably clever and expe-
LK>  rienced people can fail to learn. And the language designer admits
LK>  this. I hear warning bells. Does anyone know of `reasonably clever
LK>  and experienced people' who have failed to grasp Objective C, in
LK>  comparison?  In my view, this happens not because of `wrong expec-
LK>  tations', but because of inherent problems in C++.

We might want to draw a parallel here with other 'fields of knowledge'. How
come that some people are proficient in lets say math and others are profi-
cient in speaking (human) foreign languages. How come that one often sees
that members of the first group are far less proficient in the area of the
other group. We just don't know. Well, then, on a similar note, it is enti-
rely possible that 'reasonably clever and experienced people' somehow are
by chance just not psychologically equipped to grok C++. Or Objective-C.
Or COBOL. Or programming at all. Blame the tools in such a case?

Then, pray tell me, what are the inherent problems of C++ as opposed to
Objective C that possibly inhibit 'rcae-people' not to be able to learn
C++, and, as a challenge to an obviously entrenched Objective-C programmer
(just to rattle the chain a bit ]->) what are the inherent problems of
Objective C as opposed to C++ that inhibit the same to learn Objective-C.

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

LK>[Bjarne's long explanation of adding language features into C++, and
LK> how people's criticism changed to some other `lack' after each addition,
LK> deleted.]
LK>
LK> Again, in my opinion, this section reinforces my opinion that the
LK> _reason_ that C++ became as complex as it now is, was because
LK> Bjarne continually added features because people said `C++ is no
LK> good because you can't <XXX> with it.'  And especially, that he
LK> tried to make sure that you could write code that would run as fast
LK> as the equivalent C code. For me, that section explained _why_ C++
LK> is too complex.

Let me disect what you are implying here. You imply that Mr. Stroustrup
went into creeping-featurism-mode because somebody made a remark that
C++ was no good because you could not do <XXX> with it, without questio-
ning the reason for such a remark and without thinking wether it would
fit into the underlying philosophy of C++. If you do imply this, I resent
that, if you don't, I resent myself for saying it. However, the basis of
C++ IMHO is to develop a practical tool that would allow the people that
were able to learn to use it to work faster without incurring intolerable
extra overhead. If you closely read the ARM, you'll notice at least a few
sections that explain that the rationale behind a certain change was
instigated by practical use of the language.

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

LK> I'd add:
LK>
LK> Yes, because the language is so complex it's extraordinarily hard
LK> to write a good compiler for it.
LK>
LK> I mean, it's either that, or only bad compiler-writers were put to
LK> work on the task. I know  which explanation seems more likely to me.

Which one seems more likely to you then. As a challenge, mention to me one
language of which the first compiler was an adequate tool. Even stronger,
mention to me one program that did what a programmer originally intended.
How easy then to attribute the lack of quality to the complexity of the
design. I'll add a few:

 Yes, but we did have a deadline that was too tight
 Yes, but we wanted to release it earlier than our competitor
 Yes, but we didn't have enough understanding of the design
      in the first version
 Yes, but we didn't have the means to attract enough experts
      in the field
 Yes, <<insert your favorite excuse for botching a software
      project here>>

I happen to agree with Mr Stroustrup here. Bosh indeed. The quality of
available tools is not a function of language complexity, the quality of
tools is a function of the quality of implementation. If it's hard to
implement and you're not up to it, then don't do it.

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

LK>  Absolutely.
LK>
LK> Some groups in the company I work for, use C++ and are very happy with
LK> it.  Others dislike it just as strongly (I'm one of these).  Interes-
LK> tingly, he turning point for me was the highly-educational internal
LK> `C++ Coding Standard' document that was prepared in-house.  I read it
LK> with an open mind, but it was this document, with it's 90 rules and
LK> 15-or-so pitfalls and traps to avoid, that crystallised my current
LK> opinions on the language. The document was written by highly
LK> experienced and intelligent C++ users, who were also firm advocates of
LK> C++, as a matter of interest.

Again, you're implying that it is the complexity, or in you opinion, the
failure of C++ that instigated a standard with (my interpretation) "too many
bloody rules and a load of stupid pitfalls". Pray tell us, how many of the
rules apply to program organization, how many could be applied to other
languages as well, how many just did set a standard in the way a sourcefile
should be organized, and how many pitfalls could equally be attributed to
any C dialect as well? And, how many "bloody rules and stupid pitfalls to
avoid" does the coding standard for Objective-C have in your organization?
And how many do apply to etcetcetc...

What is the point of all this then? The point is that in my opinion, you
fail to notice a legitimate call for honesty and professionalism, and try
to perpetuate just the thing Mr. Stroustrup has tried to stop, that is,
trying to blacken C++ with 'politics' as defined above.
--
Grtz, RFP ;-)

   |o|  Ruurd Pels, Kamgras 187, 8935 EJ  Leeuwarden, The Netherlands  |o|
   |o|            EU.net!sun4nl!wtrlnd!maxine!autpels!ruurd            |o|

[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
from C syntax (@ keywords, [method-call]), looks and feels more like
"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) {
    case 'a'...'z', '\n', '@':
        ....;
        /* 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                [                  ||]~
mcv@inter.NL.net         ce .sig n'est pas une .cig

In article <D0pJ8w.438@research.att.com>,
Andrew Koenig <ark@research.att.com> wrote:
>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]

>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]

>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?

>
>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.

>Luke> ``C++ compilers/tools are too buggy''
[deletia]

>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++]
>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

Luke Kendall (luke@research.canon.oz.au) wrote:

: > 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 eighteen 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.


--
------------------------------------------------------------------------------
| David James Hanley  -- dhanley@lac.eecs.uic.edu  -- C++, OOD, martial arts |
| 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.

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> from C syntax (@ keywords, [method-call]), looks and feels more like
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 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?

Miguel> C
Miguel> =

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

Miguel>     inspect(e) {
Miguel>     case 'a'...'z', '\n', '@':
Miguel>         ....;
Miguel>         /* no break; */
Miguel>     default: ...
Miguel>     }

Ah, I get it.  C++ is too big and complicated, so you want to add to it.
This seems to be a common temptation.  Bjarne tells me that when he
sent his paper to the History of Programming Languages conference,
every single reviewer said the paper was too large and then gave
him a long list of things to add.

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.

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

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

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

Every C++ compiler I know checks function return types in all the circumstances
that K&R C does.  Most C compilers will miss

 extern int foo();

in one translation unit and

 long foo() { /* ... */ }

in another for exactly the same reason that C++ compilers will miss it,
namely that the linkers aren't smart enough.  If you are implementing C++
and have the luxury of implementing the linker as well, then of course you
should make the linker check function return types.

This is scarcely relevant to the C++ language.  It is purely an implementation
issue, and some C++ compilers do enforce return type consistency.

Miguel> The encoding scheme discussed in the ARM is not standard: every vendor
Miguel> can (and does) implement this in their own way.  I thought one of the stated
Miguel> objects of C++ was being as compatible as possible with C.  Now it's not
Miguel> even compatible with itself.  What happened to (object) code reusability?

Nothing.  I have two mutually incompatible C compilers on my workstation
and know of another C compiler that can use one of two mutually incompatible
strategies for generating object code.

Miguel> Yes, I know, you can export functions as extern "C"... yet another ugly
Miguel> language extension.

You mean that you don't like it, for unspecified reasons.


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

More innuendo.

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

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

Yes it is.  The original implementation of C++ generated C so that it
could be ported easily to a wide variety of machine architectures.
It was particularly important to make it possible for that porting to
be done by people other than the original implementers.

Rewriting or wrapping the linker would have increased the porting effort
by at least an order of magnitude.  I suspect that requiring the linker
to be rewritten would have raised the barrier high enough that C++ would
never have succeeded.

In order for a language to be useful, it must first be available.
That may sometimes limit what it can do, but that's life.

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

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

Well, if that's your biggest criticism of C++, I'll be happy to count
you as a supporter.
--
    --Andrew Koenig
      ark@research.att.com

In article <D0s1Fu.FJI@inter.NL.net>,
Miguel Carrasquer <mcv@inter.NL.net> wrote:
>In article <D0rBz6.CMB@research.att.com>,
>Andrew Koenig <ark@research.att.com> wrote:
>>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.

>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...

In article <D0rBz6.CMB@research.att.com>,
Andrew Koenig <ark@research.att.com> wrote:
>
>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...

>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++).

>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.

>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...).

>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.

>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                [                  ||]~
mcv@inter.NL.net         ce .sig n'est pas une .cig

lenngray@netcom.com (Lenny Gray) writes:
>Taylor Hutt (thutt@clark.net) wrote:
>: 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 "oral 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

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

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

> 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.

> 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.

> 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''
>
>  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 eighteen 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.

>  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''
>
>  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''
>
>  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.


> 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?

>  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.


--
Luke Kendall, Senior Software Engineer.      | Net:   luke@research.canon.oz.au
Canon Information Systems Research Australia | Phone: +61 2 805 2982
P.O. Box 313 North Ryde, NSW, Australia 2113 | Fax:   +61 2 805 2929

luke@research.canon.oz.au (Luke Kendall) writes:

>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
xmsb@borland.com
mosigbit@armory.com