Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pacbell!att!ihlpb!nevin1
From: nevin1@ihlpb.ATT.COM (Liber)
Newsgroups: comp.lang.c++
Subject: Philosophy in designing C++ (was: Static data members in C++ classes)
Message-ID: <9247@ihlpb.ATT.COM>
Date: 22 Dec 88 02:19:05 GMT
References: <424@aber-cs.UUCP>
Reply-To: nevin1@ihlpb.UUCP (55528-Liber,N.J.)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 57

In article <424@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:

>The comment I have delayed is that in C++ there often are no concise and
>thoughtful answers to wonderfully obscure questions. Usually there are no
>answers at all, because Bijarne Stroustrup did not bother with a lot of
>detail, and in the process of evolving the language, he hasn't given much
>time to clarification. To him C++ is still much of an experimental language.

Or maybe he hasn't clarified some of the "dark corners" of C++ because
making the wrong decision would impact the language in a negative way.
From what I have read of Bjarne's papers, all of his decisions are
accompanied by detailed explanations of how he arrived at his
conclusions, as well as pointing out the problems with the other
possible solutions.  This is a far better method of design than just
arbitrarily deciding how things should be.

>As Michael Tiemann has written, if only somebody cared to define exactly what
>the rules are in so many cases (especially visibility), many surprises would
>be spared even to the wary, and many small incompatibilities between cfront
>and g++ would not exist.

I not only care to have those cases defined, but I also care to have
them defined so that that they are consistent with the rest of the
language!  I want the definitions to make sense!  I feel that it is
much, much more important to wait until those decisions can be reasoned
out, than to have those decisions made prematurely, thereby hindering
the language forever.  It is much harder to take something out of the
language once people have written code dependent on it than it is to
add a definition when a reasonable choice can be made on what that
definition should be.

>In general, I like the choices Tiemann has made to resolve ambiguities.  I
>like them better than those apparent from cfront 1.2 behaviour.

The folks at GNU seem to be resolving ambiguities by deciding what is
better for the *compiler*, and not what is (necessarily) better for the
*language* (as evidence, I point to the recent discussion on why G++
uses an LALR(1) grammar, instead of using the language defined by the
C++ book).  Designing a language is very different process than designing
a compiler for a language.  Defining the language based on how you want
to write the compiler tends to lead to trouble.  One of the faults of C
is that it was designed to compile down to PDP-11 assembler (ex: in K&R-1
C compilers all floating point numbers are promoted to doubles for
the purposes of doing calculations).  It may help in the short term,
but in the long term the language tends to suffer.

Note:  studying cfront behavior is not the way to resolve the
ambiguities, either.  Try to use only the constructs which have
well-documented interpretations, and be prepared to someday rewrite code
that is strictly dependent on how your compiler does things.



Waiting a short while is a small price to pay in order to get a nice,
usable, consistent language.  It beats the alternative of making rash,
arbitrary, short-term decisions.
-- 
NEVIN ":-)" LIBER  AT&T Bell Laboratories  nevin1@ihlpb.ATT.COM  (312) 979-4751