In article <94074.173947NKEW@ESRIN.BITNET>, <NKEW@ESRIN.BITNET> writes:
|> Eddy Kim writes:
|>
|> > Are there any plans to standardize the extentions?  Its irritating to have
|> > to change all my .cpp (msdos) to .C (unix) files and #include's.
|>
|> No, no, NO!!!   DON'T standardise filenaming!
|>
|> I think it is a fault of compilers to look for particular attributes

This might be a sound argument if ths issue of handling filename extensions was
restricted to compilers.  However, the argument is erroneous because there are
non-compiler, system specific processing that occurs based on the filename
extension.  The lack of a standard extension (I prefer .CC) has, is and will
continue to create portability problems.  Eddy Kim mentioned a perfect example.
The C++ compilers for Unix appear to have standardized on .C, while the MSDOS/NT
world appears to have settled on .cpp as the extension fo choice.  In the case of
developing applications for both Unix and NT this requires multiple source trees
to be maintained (raising development cost drastically.) because a Unix file with
an extension of .cpp is submitted to the C preprocessor.  This was an established
fact long before C++ and shoulld have been addressed at the beginning.

If your development is limited to one system environment this present no problem.
If you want to support you applications on multiple and diverse platforms this is
a major development headache.

Laying the blame on the lazyness of compiler vendors and fighting against a
standardization does a disservice to those in the industry who have to support a
multiplatform environment.

Pejohnso@ingr.com

I just posted in a parallel comp.lang.c++ thread, then thought to look here.

Eddy Kim writes:

> Are there any plans to standardize the extentions?  Its irritating to have
> to change all my .cpp (msdos) to .C (unix) files and #include's.

No, no, NO!!!   DON'T standardise filenaming!

I think it is a fault of compilers to look for particular attributes
(extensions) in file NAMES, and will always give rise to porting misery.
If we standardise, we only *encourage* the wretched compiler writers!
The constraints imposed by operating systems are quite bad enough!

Instead, let's have compilers which read and compile whatever they are given,
be it file names, piped input (eg from my_preprocessor), or whatever!

If a compiler wants to accept files selectively on the basis of OS-specific
attributes NOT being part of the visible filename, that is reasonable,
and could be used as the basis for filters in programming environments.

Nick Kew
nick@mail.esrin.esa.it

This is one of those messy "real-world" questions that cannot be addressed by
a standards body, but is nonetheless very important for portability.  I'll
give an opinion based on experience.  ".cxx" works (or with trivial effort
can be made to work) in MacIntosh, DOS, Windows (3 & NT), OS/2, VMS, and UNIX
(Sun, IBM, HP, DEC, SGI, DG).  Don't know about other UNIXes, Amiga, IBM
mainframes, embedded system cross-compilers, etc.  Case distinction, funny
characters, more than 8 in the name part (thankyou, DOS), etc. are also bad
for maximum portability.  Hope this helps.