Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!rex!ames!vsi1!octopus!sjsumcs!horstman
From: horstman@mathcs.sjsu.edu (Cay Horstmann)
Newsgroups: comp.lang.c++
Subject: Re: namespace (rethought & reiterated)
Message-ID: <1991Feb6.155227.553@mathcs.sjsu.edu>
Date: 6 Feb 91 15:52:27 GMT
References: <uh311ae.665663860@sunmanager> <1991Feb4.231633.4164@cbnewsm.att.com> <4e2Gwz9f@cs.psu.edu>
Distribution: usa
Organization: San Jose State University - Math/CS Dept.
Lines: 38

In article <4e2Gwz9f@cs.psu.edu> schwartz@karl.cs.psu.edu (Scott Schwartz) writes:
>
>gregk@cbnewsm.att.com (gregory.p.kochanski) writes:
>   Well, first, forcing the use of this feature would break all C and C++
>   code in the universe.  I don't think that that is desireable.
>
>Without commenting on the specific proposal that inspired this reply,
>I observe that this very argument has been used to nuke all sorts
>suggestions in the past, which is a shame.  

I absolutely concur.

Look at ANSI C function prototypes. They were upwardly compatible with 
K&R C. Starting with C++ Version 2 and type-safe linkage, the compatibility
is basically gone. You can still link K&R C and C++, but you can no longer
mix source code in the same file. You CAN, however, often use the same
compiler, with different flags, to compile K&R C and C++ code, if you have
to.

Look at "assignment to this". Here is a classical example of a poorly
thought out feature in a new language. There should be some way of getting
rid of those features when necessary. 

There are lots of dumb syntactical quirks in C++. For example, it would
be very rational to use "private" and "public" on the module level instead
of "static" and "". 

I for one wish that the ANSI C++ committee had the courage to address 
these issues and do these cleanups [I have lots more to suggest] once
and for all, no matter how much C code they break. Of course their choice
of the ARM as the "base document" doesn't look promising. 

I have followed with great interest the discussion on smart pointers and
on namespace problems and find that some solutions to these problems should
be incorporated into a future version of C++. But the mantra "it will 
break gobs of old code" can easily frustrate all discussion. 

Cay