Re: The Dreaded "Missing Subunits"

[Robert A Duff <bobduff@shell01.TheWorld.com>]

dennison@telepath.com (Ted Dennison) writes:

> Simon Wright <simon@pushface.org> wrote in message news:<x7vu1kss4q2.fsf@pushface.org>...
> > Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > 
> > > The sad thing is that although Ada is very portable in many
> > > respects, the community of compiler vendors can't agree on
> > > file-naming conventions.  Contrast with C, where everybody knows
> > > what .h and .c mean.
> > 
> > Is this a joke?

No, I wasn't joking.

>... cos it's clear that .h and .c have absolutely _no_
> > semantic content!

Sure they do -- to programmers.  The "semantic content" is merely a
convention, not enforced by compilers.  But that's OK -- at least
you can write a bunch of .c and .h files, using the normal convention,
and expect it to compile using *any* C compiler.

I realize that in rare cases, C programmers violate the convention.
But these cases are very rare indeed, in my experience.

Contrast with Ada, where GNAT wants .ads/.adb, Rational wants
.1.ada/.2.ada, and AdaMagic wants .spc/.bdy.  I know GNAT and AdaMagic
have ways of overriding the convention (not sure about Rational),
but you have to go to extra trouble to use a convention different
from what the compiler wants.  Wouldn't it be better if all Ada
compilers supported the same file-naming conventions out of the box,
without using nonstandard pragmas Source_File_Name and the like?

What file-naming convention should I use, if I want to be
portable across all compilers?  For C, the answer is easy.
For Ada, it's not.

> It must be. The problem is that most folks *think* they know what
> those extensions mean, but the compiler could care less what you
> think.

But *all* C compilers are capable of compiling C programs consisting of
the usual .c and .h files, without any extra trouble.

> For instance, Tornado (the vxWorks development enviroment) comes with
> quite a few .c files that are "#include"d rather than compiled. Good
> luck figuring that out!

Beside the point.

> And of course most folks feel that C++ should have its own extensions,
> but there is little agreement on what they should be.

Yes, but I hope you're not one of those folks who think C/C++ is a
language.  ;-)  C and C++ do share some problems.  (As one of the
designers who turned Ada 83 into Ada 95, I feel some kinship with Bjarne
Stroustrup!  Upward compatibility is not easy.)  But for this particular
issue, C wins (even though the convention is "merely" a cultural
convention, and is sometimes violated) -- *I* didn't mention C++.

>... ".cpp" seems
> common, but I've also seen ".C" and ".cc". The extension ".c" is
> sometimes used to mean code that is purposely C compatable, while
> sometimes its used for C++-only files. For headers I've seen
> personally or seen suggested ".h", ".hpp", ".d", "..c", ".hh", and
> ".icc" (for inline header files). The C++ standard itself specifies
> that quite a few header files have no extension at all!
> 
> Of course no matter what you use, the compiler won't care a bit, and
> will happily include a ".cpp" or compile a ".hpp", if you tell it to
> and the syntax passes.

I guess that's my point: most Ada compilers *do* care, and they favor
*different* conventions.  At least in C++ you can *choose* some
convention that works easily on all compilers.

> References: http://www.cs.umd.edu/users/cml/cstyle/

- Bob