Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!ut-emx!slcs.slb.com!asc.slb.com!hargrove
From: hargrove@asc.slb.com (Jim Hargrove)
Newsgroups: comp.lang.c++
Subject: Re: file naming convensions in C++/G++
Message-ID: <1991Jun14.134741.9241@asc.slb.com>
Date: 14 Jun 91 13:47:41 GMT
References: <1991Jun13.185016.22785@johnny5.uucp>
Sender: news@asc.slb.com
Organization: Schlumberger Austin Systems Center
Lines: 33
In-Reply-To: garvey@johnny5.uucp's message of 13 Jun 91 18:50:16 GMT
Nntp-Posting-Host: bart

I don't know if our rules are the best, but here is the scheme we are
using:

Type of File            Extension

C Source                .c
C++ Source              .cc
C Headers               .h  -- These may be used in C or C++
C++ Headers             .hh -- These may not be used in C. 

Some other plans we rejected were these:
C++ Source              .C  -- Works only on systems that use case
                               sensitive file names. DOS and VMS don't.
C++ Includes            .H  -- Ditto

C++ Source              .cpp   This is OK and widely used. Takes one
                               more character, more typing.

You need to distinguish between C and C++ files so you can run the C++
compiler on the latter. Of course, you can use the C++ compiler on C
files, but this is sometimes less efficient.

You need to be able to distinguish between include files that require
C++ to make sure these aren't included into a C program.

In a sense, this is a temporary problem. When C++ becomes more
prevalent, we will probably just have a single kind of filename.
Today, though, we have tons of old software in C coexisting with new
software in C++. The scheme above lets us sort this out automatically.

-- 

        -- jwh