🚀 go-pugleaf

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>

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:
/| 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