sarima@tdatirv.UUCP (Stanley Friesen) (08/20/90)
Is there any consnsus yet on what extension to use for C++ source files? I have seen '.C', '.cpp', '.cxx, '.cc', and even '.c'! Is there any favorite, and is any of these used by more than one C++ compiler? (Every C++ compiler I have looked at is different). --------------------- uunet!tdatirv!sarima (aka Stanley Friesen) (Teradata Corp, Irvine)
joe@proto.COM (Joe Huffman) (08/23/90)
In article <124@tdatirv.UUCP>, sarima@tdatirv.UUCP (Stanley Friesen) writes: > > Is there any consnsus yet on what extension to use for C++ source > files? I have seen '.C', '.cpp', '.cxx, '.cc', and even '.c'! Is there > any favorite, and is any of these used by more than one C++ compiler? You forgot to ask about the '.hpp' files (or is '.h'). :-) Zortech assumes .c is a 'C' file, .cpp, .cxx, .cc, and .c++ are 'C++' files and invokes either the C code parser or the C++ code parser. -- joe@proto.com uunet!proto!joe FAX: 208-263-8772
bright@Data-IO.COM (Walter Bright) (08/25/90)
In article <124@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes:
< Is there any consnsus yet on what extension to use for C++ source
<files? I have seen '.C', '.cpp', '.cxx, '.cc', and even '.c'! Is there
<any favorite, and is any of these used by more than one C++ compiler?
.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.sdm@cs.brown.edu (Scott Meyers) (08/26/90)
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
bright@Data-IO.COM (Walter Bright) (08/28/90)
In article <48253@brunix.UUCP> sdm@cs.brown.edu (Scott Meyers) writes:
<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.
Zortech C++ will compile any file as a C++ file *if the filename is explicit*.
If the filename has no extension, it will try tacking on various extensions
to try and figure out what was meant.sarima@tdatirv.UUCP (Stanley Friesen) (08/28/90)
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.