Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!tdatirv!sarima
From: sarima@tdatirv.UUCP (Stanley Friesen)
Newsgroups: comp.lang.c++
Subject: Re: best extension for C++ source files
Message-ID: <134@tdatirv.UUCP>
Date: 28 Aug 90 15:26:10 GMT
References: <124@tdatirv.UUCP> <2666@dataio.Data-IO.COM> <48253@brunix.UUCP>
Reply-To: sarima@tdatirv.UUCP (Stanley Friesen)
Organization: Teradata Corp., Irvine
Lines: 24

In article <48253@brunix.UUCP> sdm@cs.brown.edu (Scott Meyers) writes:
>In article <2666@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:

>| .c makes it difficult to distinguish between C and C++ source files
>| in makefiles.
>
>And then there are those of us on real computers.  From the CC man page
>(i.e., cfront):
>
>     CC takes arguments ending in .c, .C or .i to be  C++  source
>     programs.  .i files are presumed to be the output of cpp(1).
>     Both .s and .o files are also accepted by the CC command and
>     passed to cc(1).

	I think this is rather unfortunate, given Walter's comment above.
By taking .c as well as other suffixes as indicating a C++ source file, the
compiler is going to do strange things if given a normal C source file!  It
will try to compile it as C++ and get rather confused - C++ is *not* a proper
superset of C.  At the very least the treatment of function prototypes is
different, and incompatible [even more so in pre-ANSI C than now].

	I believe that it is vital to have a distinct extension for C++ and C,
and that any compiler that takes .c as meaning C++ is a problem waiting to
happen.