Xref: utzoo comp.lang.c++:10467 gnu.g++.help:161
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!snorkelwacker.mit.edu!bionet!agate!shelby!neon!pescadero.Stanford.EDU!philip
From: philip@pescadero.Stanford.EDU (Philip Machanick)
Newsgroups: comp.lang.c++,gnu.g++.help
Subject: Re: Incompatible changes in C++
Message-ID: <1990Nov20.185345.21001@Neon.Stanford.EDU>
Date: 20 Nov 90 18:53:45 GMT
References: <9011190326.AA13113@mole.ai.mit.edu> <11645@alice.att.com>
Sender: news@Neon.Stanford.EDU (USENET News System)
Reply-To: philip@pescadero.stanford.edu
Organization: Computer Science Department, Stanford University
Lines: 33

In article <11645@alice.att.com>, ark@alice.att.com (Andrew Koenig) writes:
|> 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.
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.)
-- 
Philip Machanick
philip@pescadero.stanford.edu