Xref: utzoo comp.lang.c++:10591 gnu.g++.help:202
Path: utzoo!utgpu!watserv1!watmath!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++,gnu.g++.help
Subject: Re: Incompatible changes in C++
Message-ID: <59404@microsoft.UUCP>
Date: 28 Nov 90 18:52:04 GMT
References: <9011190326.AA13113@mole.ai.mit.edu> <11645@alice.att.com> <1990Nov20.185345.21001@Neon.Stanford.EDU>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 38

In article <1990Nov20.185345.21001@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes:
|In article <11645@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
||> 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.

|I second this. Even with programs only a few hundred lines long (one
|of which is in widespread use), I've discovered errors when converting
|from C to C++. Sometimes, it's worth breaking a few programs to improve a
|language - the effort required to do the repairs pays off in cutting the
|number of bugs to be searched for. (None of this of course is an argument
|for gratuitous changes.)

I believe these examples and other similar show that the complaint that
C++ is not _exactly_ ANSI-C is a red herring.  The real problem in
moving a program from one compiler to another is overcoming program
dependencies on implementation defined issues.  The practical
differences between ANSI-C and C++ are small compared to the number of
issues both leave implementation defined.  As pointed out above, at
least C++ provides a number of features that help detect these bugs
at compile time.  So my claim is that in general making some features
of C++ more type safe than ANSI-C actually helps in porting software from
one compiler to another -- even if there is an initial hurdle of small
changes one has to make in order to get old code to compile.  Once you
do get it to compile under C++, you have a much better chance of it
actually working.  It is more important to make C++ _strictly_ typed
and _object oriented_, than to make it _ansi-c oriented_.