🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.g++.help
Article #303

Re: Incompatible changes in C++

#303
From: Henry Spencer
Date: Mon, 19 Nov 1990 19:51
41 lines
3038 bytes
In article <11635@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
>X3J11 did indeed show restraint in what they did to C and I hope X3J16
>will show similar restraint. It should be remembered that X3J11 did do
>a few interesting things to C. Notably it added `const,' prototypes
>(both adapted from C++), locale in libraries, w_char, the rules for
>unsigned arithmetic, etc. (in such cases C++ has followed ANSI C).

My point was not so much that X3J11 didn't do anything to C, but that they
didn't do very much that *some* existing implementation hadn't already done.
The unsigned-arithmetic rules, for example, existed in production compilers
well before X3J11 adopted them.  (There is a common syndrome in which X3J11
gets blamed for "inventing" anything that wasn't in the Unix C compilers,
but there have been other C compilers in the world for over a decade now.)
Prototypes and `const' were a borderline case, but early versions of C++
were pretty close to C and I think they were right in deciding that the
experience could be read across.  I believe the locale stuff existed at
HP.  w_char I am not sure about.  But overall, almost everything in ANSI C
is based on prior experience with C or C derivatives *somewhere*, and the
few things that were invented out of whole cloth -- notably `noalias' and
trigraphs -- were conspicuously poor ideas (in the case of `noalias',
sufficiently so to get it removed).

Although I'm not as happy with C++ as I used to be, I have little quarrel
with the idea of standardizing things that have been implemented and are
used successfully **in C++ or a derivative**.  I might think that feature
X is a dumb idea, but that's another question.  The numbers Bjarne cites
make it clear, in particular, that templates are well understood and are
appropriate for consideration by X3J16.

What concerns me is exception handling.  The article I was originally
responding to had a distinct air of "we're going to standardize something
like Bjarne's proposal; if we don't like it, we'll tinker with it until
we do".  This is why I hoisted storm warnings. :-)  I'm not convinced
that this feature has had enough implementation and use in C++ to be a
legitimate candidate for standardization at all -- confidence in the people
who designed it is not a substitute for real experience -- and committee
modifications to it are an invitation to disaster.  Storm warnings don't
mean that your house *will* blow down; they just denote cause for concern.
-- 
"I don't *want* to be normal!"         | Henry Spencer at U of Toronto Zoology
"Not to worry."                        |  henry@zoo.toronto.edu   utzoo!henry
Technical Details
Message-ID: <1990Nov19.195128.18538@zoo.toronto.edu>
Path: arc1-ca.pugleaf.net!utzoo!henry
References: <9011171750.AA29372@mole.ai.mit.edu> <11635@alice.att.com>

Show Full Headers
Complete Article Headers
Newsgroups: gnu.g++.help,comp.lang.c++
Path: arc1-ca.pugleaf.net!utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Incompatible changes in C++
Message-ID: <1990Nov19.195128.18538@zoo.toronto.edu>
Organization: U of Toronto Zoology
References: <9011171750.AA29372@mole.ai.mit.edu> <11635@alice.att.com>
Date: Mon, 19 Nov 90 19:51:28 GMT