Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!brunix!sdm
From: sdm@cs.brown.edu (Scott Meyers)
Newsgroups: comp.lang.c++
Subject: Re: best extension for C++ source files
Message-ID: <48253@brunix.UUCP>
Date: 26 Aug 90 04:19:58 GMT
References: <124@tdatirv.UUCP> <2666@dataio.Data-IO.COM>
Sender: news@brunix.UUCP
Reply-To: sdm@cs.brown.edu (Scott Meyers)
Organization: Brown University Department of Computer Science
Lines: 35

In article <2666@dataio.Data-IO.COM> bright@Data-IO.COM (Walter Bright) writes:
| .cpp is used by:
| 	Zortech C++
| 	Borland C++
| 	Guidelines C++
| 
| .C is not very useful, because it doesn't work on case-insensitive
| operating systems (like DOS and OS/2).
| 
| .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).

And the g++ texinfo file:

    File names which end in `.c', `.cc', or `.C' are taken as GNU C++
    source to be preprocessed and compiled; compiler output files plus any
    input files with names ending in `.s' are assembled; then the resulting
    object files, plus any other input files, are linked together to
    produce an executable.

Personally, I believe that compilers should compile any file fed to them,
regardless of the file extension, but that seems to be a renegade position.
At any rate, isn't it comforting to know that the intersection of
acceptable file extensions for the various C++ compilers is ambiguous in an
environment where C files also exist?

Scott