rms@AI.MIT.EDU (Richard Stallman) (11/21/90)
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.
This should make conversion easier. I mentioned this apparent problem
(which I learned of from Stroustrup's book) to Stroustrup a couple of
years ago, and he didn't say the problem was solved, so I took that as
confirmation it did exist. Sorry.
I still think it would have been better not to change the meanings
of struct and union.
> 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.'
Sure, you can resolve an ambiguity by chosing an order of priority of
the possible interpretations, but that isn't nearly as clean as
designing the syntax so there is no ambiguity.
> 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.
It seems people have assumed that I am complaining about difficulty in
implementing these features. That's not what I have in mind. It is
as a potential user that I value compatibility and unambiguity. It
puzzles me that anyone thinks of them as user convenience.
The ambiguity means that certain features don't work in particular
combinations, because they are interpreted as other features instead.
Of course I can avoid such problem cases, but I still prefer a
language where the features are clearly delimited and not subject to
confusion with each other.
The incompatibility of struct and union (that may not exist) seemed to
me a significant practical reason not to *use* C++.
Requiring prototypes is another practical reason. Prototypes are a
good feature, and it is useful to offer a feature to warn about
functions that don't use prototypes, to aid conversion. But there is
no need to reject old-style function definitions and declarations.
ANSI C demonstrates that they can be accommodated and do not cause
trouble for the type structure.
However, that problem is not so severe, because it is (I think)
possible to extend C++ compatibly now to accept C code without
prototypes.
One person told me that compatibility with C does not matter because
all C programs are worthless anyway, and people should rewrite them
from scratch. In general, rewriting a program allows improvements
to be made, but sometimes it is more work than one can afford to do.