In article <1993Jan12.153045.15612@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
/In article <1569@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
/| Zortech C++ will recognize .cpp, .cxx, .cc and .c++ all as valid C++
/| filename extensions, though our examples all use .cpp.
/I have never been able to fathom why any compiler *cares* what file
/extension is used.

Because the driver program recognizes ASM, OBJ, C, C++, EXE, COM, LIB,
DEF files, etc., and tries to do the obvious thing with it. For instance,
if a .EXE file name is given, the driver assumes that is the name of the
output file wanted.

Also, the driver tries on various extensions if the user didn't type in
one. This can be a nice convenience.

If all else fails, the driver assumes it is a C++ or C program, depending
on if the -cpp is used or not.

As to whether a #include file is .h or .hpp or whatever, makes absolutely
*no* difference to the driver.

In article <1993Jan14.164336.23286@taumet.com>, steve@taumet.com (Steve
Clamage) writes:
|> This presupposes the common model of separate text files which are
|> processed by an identifiable compiler program, and that the text
|> files are kept in a file system using names files containing a
|> user-definable extension.
|>
|> Absolutely none of this is required by the C++ language, so you
|> can't
|> put the required file extension in the C++ language standard.
|> --
|>
|> Steve Clamage, TauMetric Corp, steve@taumet.com

If I may divert discussion from the name of a compilation unit to a header...

I disagree; the C standard supports the characters ".h" on the end of stuff
between angle brackets in #include preprocessor directives; do you think that
the C standard "presupposes the common model of separate text files"?

Of course, the alternate solution to this favored by the C++ committee(s)
(the last I heard; apologies if this solution has already been discussed here)
is to not require such characters on the end of the standard headers' names,
e.g. #include <iostream> (and if the implementation keeps these in files with
some particular file extension, it can supply the extension).

- Aron Insinga, insinga@tle.enet.dec.com

In article <WARSAW.93Jan13142300@anthem.nlm.nih.gov>, warsaw@nlm.nih.gov (Barry A. Warsaw) writes:
>
> >>>>> "Jeffrey" == Jeffrey R. Brown <jb8285@medtronic.COM> writes:
>
>     Jeffrey> One is whether there should be a standard file extension
>     Jeffrey> for C++ files and, if so, what it should be.
>
> As mentioned before, the only "standard" necessary is whatever
> convention your project group agrees to based on your particular
> situation (i.e. no "official" blessing is necessary).

I don't think so. If I develop my software system on a bunch of
different operating systems and with a common file system (let's say,
via NFS) I want to have common extensions which are recognized by
*all* programs, not just by the compiler.
    It's a nuisance that make, RCS, etc. don't know properly about
commonly used extensions. And especially for small programs which
should readily run everywhere, it's annoying. Assume for a moment
that your yacc/lex produces code which may be compiled by C++. Now
try to write a short yacc/lex program with C++ actions and formulate
a reliable (ie, portable) Makefile which may be used without
changing. It's a hassle. I know why I use imake for such small
stuff...

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod   Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany

sdm@cs.brown.edu (Scott Meyers) writes:

|I have never been able to fathom why any compiler *cares* what file
|extension is used.  If I want to call my C++ source file foo.bar.baz, why
|should the compiler give two hoots?  ...

I'm not aware of any compiler that isn't happy to accept files with
arbitrary extension, if only you are willing to tell it what kind
of file its actually accepting.  Which only leaves the issue of
standardizing how one tells one's compiler what kind of file to accept....

steve@taumet.com (Steve Clamage) writes:

> jb8285@medtronic.COM (Jeffrey R. Brown) writes:
>
> >I think that there should be a standard file extension.  This is not
> >to make compiler writers' lives easier, but for everyone else, so that
> >the source code is identifiable easily in a directory listing.
>
> This presupposes the common model of separate text files which are
> processed by an identifiable compiler program, and that the text
> files are kept in a file system using names files containing a
> user-definable extension.
>
> Absolutely none of this is required by the C++ language, so you can't
> put the required file extension in the C++ language standard.


I don't think even the original poster was suggesting that it be
part of the official C++ standard.

Last time I cared to check, the '.c' extension wasn't in the ANSI-C
standard either, but I've only rarely seen C source files in any
package I've looked at.

I agree that it is very frustrating having to cope with different
naming conventions; it breaks scripts and makefiles, and is very
user UN-friendly. It's even more frustrating when using an OS
with a case-insensitive filesystem where the compiler automatically
determines the file type from the extension. Even worse is trying
to untar a package where '.C', '.c', '.H' and '.h' files all of
the same name exists in the same directory.


david


.........................................................
david nugent
davidn@csource.oz.au  Unique Computing Pty Ltd, Melbourne, Australia
The opinions expressed above are that of the author only.

One issue I haven't seen raised in this discussion (but which has arisen multiple
times in work situations where we are trying to decide on project-wide standards
for naming is file name length limitations.

in a unix environment, you often want to be portable to system V systems which have
a file name limit of somethinglike 15 characters. you also want to have reasonably
descriptive names. so that seems like a good reason to use .C in a unix envirinment
rather than .cpp or .cc. Other platforms may have different issues.

what are thoughts about this?
(keep in mind that a 15 char limit really means less if you allow for
 a ,v for the RCS file and teh "." between file name and extension and
 any subsystem prefixes you might establish at your work site)

--
Steve Berczuk   berczuk@mit.edu
MIT Center for Space Research (617) 253-3840

In article <1993Jan7.182757.8297@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
/It would be really nice if everybody
/agreed on some common extension; I'm tired of wrting batch files to
/rename things, and shell scripts to build symbolic links when I switch
/from one platform to the other.

Zortech C++ will recognize .cpp, .cxx, .cc and .c++ all as valid C++
filename extensions, though our examples all use .cpp.

In article <1569@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
| In article <1993Jan7.182757.8297@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
| /It would be really nice if everybody
| /agreed on some common extension; I'm tired of wrting batch files to
| /rename things, and shell scripts to build symbolic links when I switch
| /from one platform to the other.
|
| Zortech C++ will recognize .cpp, .cxx, .cc and .c++ all as valid C++
| filename extensions, though our examples all use .cpp.

I have never been able to fathom why any compiler *cares* what file
extension is used.  If I want to call my C++ source file foo.bar.baz, why
should the compiler give two hoots?  Certainly my text editor, my document
editor, my mail-reading program, etc., is happy to read/write whatever
files I tell it to.  Why do compilers insist on being so fascist?

Many compilers can actually parse more than one language (e.g., K&R C, ANSI
C, C++, Objective C), and they use the extension of the source file to
determine which parser to use, but certainly there is no reason why they
can't have a default mode and a command-line switch to tell them which
parser to use in the event that a non-standard extension is used.  Last I
looked, gcc did this.  Similarly, the command cc, CC, gcc, g++, etc., is
often more than a compiler, also invoking an assember, loader, etc.,
depending on what is passed in as an argument.  Still, there is no reason
why such tools shouldn't take arbitrary file names as long as there are
command line options to direct the behavior of the tool for nonstandard
extensions (or to override default behavior).

Scott

-------------------------------------------------------------------------------
What do you say to a convicted felon in Providence?  "Hello, Mr. Mayor."

bright@nazgul.UUCP (Walter Bright) writes:

>In article <1993Jan7.182757.8297@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>/It would be really nice if everybody
>/agreed on some common extension; I'm tired of wrting batch files to
>/rename things, and shell scripts to build symbolic links when I switch
>/from one platform to the other.

>Zortech C++ will recognize .cpp, .cxx, .cc and .c++ all as valid C++
>filename extensions, though our examples all use .cpp.

Not to be outdone, I should say the same is true of Oregon C++, a product
of my company.  We don't discriminate on the basis of file names, as long
as the extention starts with 'c' or 'C'.  Further, you choose C or C++
compilation with a compiler flag, not via the file name.  If you wish to
choose compilation mode on the basis of file names, you can write that
into the make file script.

If you are unhappy with the parochial attitude of your C++ compiler,
complain to the vendor, or switch to a more ecumenical one.
--

Steve Clamage, TauMetric Corp, steve@taumet.com

In article <1993Jan12.153045.15612@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
>In article <1569@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
>| In article <1993Jan7.182757.8297@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>| /It would be really nice if everybody
>| /agreed on some common extension; I'm tired of wrting batch files to
>| /rename things, and shell scripts to build symbolic links when I switch
>| /from one platform to the other.
>|
>| Zortech C++ will recognize .cpp, .cxx, .cc and .c++ all as valid C++
>| filename extensions, though our examples all use .cpp.
>
>I have never been able to fathom why any compiler *cares* what file
>extension is used.  If I want to call my C++ source file foo.bar.baz, why
>should the compiler give two hoots?  Certainly my text editor, my document
>editor, my mail-reading program, etc., is happy to read/write whatever
>files I tell it to.  Why do compilers insist on being so fascist?
>
>Many compilers can actually parse more than one language (e.g., K&R C, ANSI
>C, C++, Objective C), and they use the extension of the source file to
>determine which parser to use, but certainly there is no reason why they
>can't have a default mode and a command-line switch to tell them which
>parser to use in the event that a non-standard extension is used.  Last I
>looked, gcc did this.

I just installed gcc2.3.3 and it takes name extensions as follows :
`FILE.c'
     C source code which must be preprocessed.

`FILE.i'
     C source code which should not be preprocessed.

`FILE.ii'
     C++ source code which should not be preprocessed.

`FILE.m'
     Objective-C source code.  Note that you must link with the library
     `libobjc.a' to make an Objective-C program work.

`FILE.h'
     C header file (not to be compiled or linked).

`FILE.cc'
`FILE.cxx'
`FILE.C'
     C++ source code which must be preprocessed.

`FILE.s'
     Assembler code.

`FILE.S'
     Assembler code which must be preprocessed.


you can also pass a -LANGUAGE option to override this default
behaviour. I believe this is the latest gcc release -- and for what
its worthZ I like this scheme a lot. If you have  a directory with
mixed C and C++ files it is nice to not have to fiddle with your make
file to make sure that the right files get compiled with the right
compiler options.

 hlf

There are two issues that are being co-mingled here.  One is whether
there should be a standard file extension for C++ files and, if so,
what it should be.  The other is how compilers should "honor" the
standard file extension, or if they should allow any file name.

I think that there should be a standard file extension.  This is not
to make compiler writers' lives easier, but for everyone else, so that
the source code is identifiable easily in a directory listing.  If you
want to name your source code files with names like "foo.bar.baz"
that's fine, but don't expect anyone else to find them.  This is quite
important if the development is done using a team of people, not a
single individual.  (Just for the record, we've been using .cpp and
hpp for file extensions.)

The other isssue is how compilers and other tools handle standard file
extensions.  I think that the compilers should look for standard file
name extensions, but that there should always be a way to override
this.  (Who knows, maybe there is a reason to use .baz for C++ source
code files.)

--
"The comments and opinions expressed above are mine and do not necessarily
represent the official position or views of Medtronic, Inc."
Jeffrey R. Brown
Internet: jeffrey.brown@medtronic.com             Voice: 1-612-574-4698
UUCP:     uunet!medtron!jb8285                    FAX:   1-612-574-6150

In article <1993Jan12.153045.15612@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
>In article <1569@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:

>| Zortech C++ will recognize .cpp, .cxx, .cc and .c++ all as valid C++
>| filename extensions, though our examples all use .cpp.
>
>I have never been able to fathom why any compiler *cares* what file
>extension is used.

Excellent point... In addition, I have always wondered why C[++] compilers
won't accept input from the standard input.  On several occasions I have
wanted to be able to say

 myprog | compiler
--
Mark Harrison, mharriso@dsccc.com

In article <1993Jan12.153045.15612@cs.brown.edu> sdm@cs.brown.edu (Scott Meyers) writes:
>In article <1569@nazgul.UUCP> bright@nazgul.UUCP (Walter Bright) writes:
>| In article <1993Jan7.182757.8297@wam.umd.edu> krc@wam.umd.edu (Kevin R. Coombes) writes:
>| /It would be really nice if everybody
>| /agreed on some common extension; I'm tired of wrting batch files to
>| /rename things, and shell scripts to build symbolic links when I switch
>| /from one platform to the other.
>|
>| Zortech C++ will recognize .cpp, .cxx, .cc and .c++ all as valid C++
>| filename extensions, though our examples all use .cpp.
>
>I have never been able to fathom why any compiler *cares* what file
>extension is used.  If I want to call my C++ source file foo.bar.baz, why
>should the compiler give two hoots?  Certainly my text editor, my document
>editor, my mail-reading program, etc., is happy to read/write whatever
>files I tell it to.  Why do compilers insist on being so fascist?

Good question!

>>>>> "Jeffrey" == Jeffrey R. Brown <jb8285@medtronic.COM> writes:

    Jeffrey> One is whether there should be a standard file extension
    Jeffrey> for C++ files and, if so, what it should be.

As mentioned before, the only "standard" necessary is whatever
convention your project group agrees to based on your particular
situation (i.e. no "official" blessing is necessary).

sdm@cs.brown.edu (Scott Meyers) writes:

>I have never been able to fathom why any compiler *cares* what file
>extension is used.  If I want to call my C++ source file foo.bar.baz, why
>should the compiler give two hoots?  ...

>...  Similarly, the command cc, CC, gcc, g++, etc., is
>often more than a compiler, also invoking an assember, loader, etc.,
>depending on what is passed in as an argument.  Still, there is no reason
>why such tools shouldn't take arbitrary file names as long as there are
>command line options to direct the behavior of the tool for nonstandard
>extensions (or to override default behavior).

In our compiler driver we care only a little about extensions.  In
Unix systems, for example, the extension ".o" is used for relocatable
object files, ".a" for libraries, ".c" for C source, and so on.  We
adhere to the local convention, and attempt to detect typographical
errors like this one:
 cc -o file.c file

Rather than blindly try to compile the binary "file" as if it were
source or write over the C source "file.c" (the programmer's only
copy), we assume there is some sort of error and complain.  I've been
saved by this approach more than once.

The compiler itself, on the other hand, doesn't care at all about file
names.  It will happily try to read any file name presented to it.
--

Steve Clamage, TauMetric Corp, steve@taumet.com

On Dec. 11, 1992, I surveyed the Net to determine the most popular extension
to use for C++ code.  Each respondent was permitted multiple votes.
Here are the results:

Total votes: 72

           |      |      |      |      |      |      |
___________|__.C__|__.c__|_.cxx_|__.cc_|_.cpp_|_.c++_|
           |      |      |      |      |      |      |
In favor:  |  9   |  3   |  2   | 16   |  8   |  2   |
___________|______|______|______|______|______|______|
           |      |      |      |      |      |      |
Against:   | 12   |  7   |  5   |  1   |  3   |  4   |
___________|______|______|______|______|______|______|
           |      |      |      |      |      |      |
Total:     | 21   | 10   |  7   | 17   | 11   |  6   |
___________|______|______|______|______|______|______|

The distribution of the votes is very interesting.  The .C extension got the
most votes, but more people voted against than for it, though not by an
overwhelming majority.  Most people who voted against .C did so because it
is not appropriate for machines with case-insensitive file names, including
PC clones.  Some, however, did object to it because it is visually difficult
to distinguish from .c. The .cc extension is the least controversial, with only
a single respondent objecting to it.

Note that this distribution is counter to the advice given in the FAQ, which
recommends .C for Unix machines and .cpp or .cxx for DOS and OS/2.

Respondents agreed that there was no standard or consensus yet.

--
Peter Webb      webb@hks.com
Hibbitt, Karlsson & Sorenson, Inc.  Voice: 401-727-4200
1080 Main St, Pawtucket RI 02860  FAX: 401-727-4208

In article <1if5q2INN8pj@tsavo.hks.com> webb@tsavo.hks.com (Peter Webb) writes:
>
>On Dec. 11, 1992, I surveyed the Net to determine the most popular extension
>to use for C++ code.  Each respondent was permitted multiple votes.
>Here are the results:
>[table omitted]
>The distribution of the votes is very interesting.  The .C extension got the
>most votes, but more people voted against than for it, though not by an
>overwhelming majority.
>[more omissions...]
> The .cc extension is the least controversial, with only
>a single respondent objecting to it.
>
>Note that this distribution is counter to the advice given in the FAQ, which
>recommends .C for Unix machines and .cpp or .cxx for DOS and OS/2.
>
>Respondents agreed that there was no standard or consensus yet.

If you're really looking for a "standard", then you have no choice but
to rule out both .C and .c++, since there are operating systems that
will not support them. Of the remaining choices you listed, only  .cc
and   .cpp   got more favorable votes than unfavorable. I found that
interesting, since those are the extensions I use (the first on UNIX,
and the second on MS-DOS). It would be really nice if everybody
agreed on some common extension; I'm tired of wrting batch files to
rename things, and shell scripts to build symbolic links when I switch
from one platform to the other.

Kevin Coombes <krc@math.umd.edu>