grove@zeta.org.au (Rachel Polanskis, 16 Dec 1994, wrote:

luke>...  Interestingly, the turning point for me was the highly-educational
luke>internal `C++ Coding Standard' document that was prepared in-house. ...

> 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've been left a message that I'm not allowed to (since my manager is
overseas).  But I intend to talk to him about this early in the new year.
I'm not enormously hopeful, but I'll have a go.

Note that (sarima@netcom.com):

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

No.  It's CISRA proprietary.


Let's look at some other comments.  By the way, I apologise for not
responding earlier;  I only read the news once a week.

(Philosophical digression:

  I realised an interesting Truth from reading Andrew Koenig's
  followup.  Using analogies in a rational argument is a very `dodgy'
  technique.  Analogies vary from very good to very misleading.

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

  What about if we suggest that it takes as long to learn how to construct
  an atom bomb?  Do you see my point?

  Anyway, you can waste enormous effort arguing about the validity of
  the analogy, instead of the real facts under discussion.

  Analogies are sort of ok when used as the 1st step in teaching a new
  concept;  but they're ill-suited to constructive arguments.
)


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

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

ark@research.att.com (Andrew Koenig):

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

I believe very few people would be prepared to defend C's implicit
ampersand for arrays and functions.  But you've missed the point -
when you pass in a pointer to a function, having the `&' there is a
bonus.

Admittedly you don't get the bonus when you pass in a variable
that already _is_ a pointer, but being able to use the `&' when
you can, is a bonus.

<shrug>  To me it seems ludicrous that some C++ texts _encourage_
the use of ref variables to lose this bonus piece of documentation.

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

Amazing.  I'm afraid I'd have to test this assertion in practice, though,
before I could accept it.  It certainly contradicts what the C++
programmers here believe.  And these are highly intelligent people.
Basically, their impression is that it would take 6 months to become
competent, and another year to appreciate all the finer nuances.

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

The length of the `rejected' list is a mere smokescreen, if you think
about it.  The list of added features is all that is significant.
In my opinion, that list is too long.

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?

Too complex for me.  I'm an intelligent person (you can choose to believe
or disbelieve this as you see fit :-), and that's my opinion.  Many
other intelligent people I've discussed it with, and who have had some
experience with it, agree.

And quite a few intelligent people disagree with me, and think it's not
too complex.

In my opinion, the argument comes down to that judgement, in the end.  And
to resolve that dispute, I believe only time will tell.  If I'm right,
lots of large C++ projects will be late, and collapse under their
own weight.  If I'm wrong, the elegance and maintainability of these
C++ projects will give a competitive edge to the people who developed
them.

luke

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

In article <nagleD0sEtJ.Ltr@netcom.com>, nagle@netcom.com (John Nagle) wrote:

I read *Bjarne's Lament* all 10 printed pages of it and it was well written
and there was not much I could fault with his reasoning.  Criticism however
is an important issue in us getting what we require.  I have complained
about C++ being too complex and clumsy, but I still use it where I feel it
gives me the most benefit.  I agree whole heartedly with you message below.

>      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

Vince
-----