Xref: utzoo comp.lang.c++:10457 gnu.g++.help:155
Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!att!dptg!ulysses!andante!alice!ark
From: ark@alice.att.com (Andrew Koenig)
Newsgroups: comp.lang.c++,gnu.g++.help
Subject: Re: Incompatible changes in C++
Message-ID: <11645@alice.att.com>
Date: 20 Nov 90 01:27:17 GMT
References: <9011190326.AA13113@mole.ai.mit.edu>
Organization: AT&T Bell Laboratories, Liberty Corner NJ
Lines: 77

In article <9011190326.AA13113@mole.ai.mit.edu> rms@AI.MIT.EDU (Richard Stallman) writes:

>     I am not aware of a  having ``change(d) the behavior of struct and union,
>     breaking almost all C programs.'' In fact, nothing C++ does to structs
>     or unions break any C programs. I suspect rms is misinformed.

> My understanding is that the following declaration

>    struct foo { int a, b; };

> is handled by C++ in a way incompatible with C.  C++ defines `foo' as
> a typedef, but C does not.

> Is this not so?  I would be glad if it is not.  But if it is, the
> incompatibility breaks many C programs because they use the same
> symbol both as a structure tag and as a variable (often a variable
> whose type is or points to that structure).

But C++ allows the same identifer to be used as a type name and a
variable name in such contexts, precisely for the purpose of preserving
C compatibility.  Of course, if you do recycle type names that way,
you must use `struct' or `class' before each occasion in which you want
to use the name as a type, just as you do in C.

> The grammar ambiguity shows up in

>    int (x);

> which could either declare `x' as an integer or convert it to one.

and which is therefore supposed to be interpreted as a declaration
in C++.  The rule is `if it looks like a declaration, it is.'

>     I think that my design choices in this area traded
>     implementor convenience for user convenience.

> I don't see that they help the implementors enough to compensate for
> the inconvenience to the users.

It's the other way around: C++ gave up implementer convenience
to gain user convenience.

> Users switching from C to C++ wish that C++ were a superset of C.

Every C++ user I know *likes* the ability to use structure names
as types without further formality.

> There is no fundamental or important reason it is not.  The real
> features of C++ are upward compatible with C.  The problems are all
> superficial.

Actually, the most significant incompatilibity between C++ and
ANSI C is that C++ treats

	extern int f();

as being equivalent to

	extern int f(void);

whereas ANSI C treats it as

	extern int f(...);

However, I believe that that treatment on the part of ANSI C is
stated to be an anachronism.

It is clear that the old treatment opens a hole in the type system
through which one could drive a moving van.

In practice, it is closing this hole that takes the most time when
converting large C programs to C++.  Doing so also usually discovers
serious errors in the programs being be converted, even when they
have appeared to work in the past.
-- 
				--Andrew Koenig
				  ark@europa.att.com