In the recent CUJ article "C and C++: Case Studies in Compatibility"
(http://www.cuj.com/articles/2002/0209/0209c/0209c.htm?topic=current),
Bjarne Stroustrup proposes several changes to C and C++ to bring the
languages into alignment.  In general I find myself in agreement with
the suggested changes, but there are two that I find unacceptable.

1.) It is suggested that C++ adopt the C rule that allows (void *) to
be assigned to any pointer to object type without a cast.

2.) It is suggested that C++ adopt the C rule that allows an int to
be assigned to an enum without a cast.

As the article asknowledges, both of these changes would weaken the C++
type system, and up to now that has been the reason the change has not
been made.  The article states (in connection with the first of the
suggested changes) that "[t]his is an example where I suggest that in
the interest of the C/C++ community, we must leave our 'language theory
ivory towers,' accept a wart, and get on with more important things".

In my opinion these issues are not "language theory ivory tower" issues,
but rather are issues of great practical importance in writing type-
safe programs.  When I made the transition from C to C++ several years
ago, I was delighted to find these loopholes closed because they had
been a persistent source of errors.  The current C++ enum rule, for
instance, makes it easy for the compiler to tell you if you inadvertently
swap arguments in a function that takes several enums as parameters;
the C rule subverts this capability.  I'd rather live with the
incompatibility that see this useful facility removed from portable C++
programs.  Similar considerations apply to assigning (void *) to
arbitrary pointers.

In my view what is needed is not to make C a proper subset of C++ but
(in order of importance)  (i) to have a common subset of both languages
that is acceptable to all standard-conforming compilers and (ii) to
eliminate gratuitous differences, particularly the ones that silently
change the meaning of code.  Currently we have (i) but could stand
some improvement on (ii).  One provision in the C++ standard that
threatens (i) is the deprecation of static;  for this reason I agree
with Dr. Stroustrup's suggestion to undeprecate static in the next
version of the standard (cf. core issues 169, 174, and 223).  One of the
suggestions in the article in line with (ii) is to allow allow old-style
function definitions with exactly the same semantics as other function
definitions;  this would be a minor change to C and C++ that would not
(in my opinion) harm uses of either language and would help compatibility.

The two suggestions that I've objected to, however, would (in my opinion)
cause significant harm to C++ users.  The incompatibilities cause
compilation failures, not silent changes of meaning, and so conversion of
code to the common C/C++ subset (by adding appropriate C-style casts) is
not difficult.  Insofar as these incompatibilities improve the type-safety
of code that is targeted to both C and C++ compilers they can be seen as
a benefit to the segment of the community that has to write such code.
I therefore urge the community to oppose these changes.

nobody

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]