jeh@cs.rit.edu (Jim Heliotis) (09/05/90)
From article <907@zinn.MV.COM>, by mjv@objects.mv.com (Michael J. Vilot): > Actually, the problem is not with source files, but with _header_ files. > It will be extremely awkward to share libraries if one vendor uses .h, > another uses .hxx and another uses .hpp. > I have always used ".H", to go along with ".C". I have never thought of a reason why this would be bad. ============================================================================== Jim Heliotis Rochester Institute of Technology Rochester, NY 14623-0887 jeh@CS.RIT.EDU {allegra,seismo}!rochester!rit!jeh ==============================================================================
poffen@sj.ate.slb.com (Russ Poffenberger) (09/06/90)
In article <1845@cs.rit.edu> jeh@cs.rit.edu writes: >From article <907@zinn.MV.COM>, by mjv@objects.mv.com (Michael J. Vilot): >> Actually, the problem is not with source files, but with _header_ files. >> It will be extremely awkward to share libraries if one vendor uses .h, >> another uses .hxx and another uses .hpp. >> >I have always used ".H", to go along with ".C". I have never thought of >a reason why this would be bad. > Ar you saying 'H' as in upper case, as opposed to 'h' in lower case? The problem with this is that some OS's are not case sensitive. Certainly DOS isn't so 'H' and 'h' mean the same thing as far as a file name goes. UNIX is case sensitive, but certainly isn't the only platform for doing C++ development. Russ Poffenberger DOMAIN: poffen@sj.ate.slb.com Schlumberger Technologies UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen 1601 Technology Drive CIS: 72401,276 San Jose, Ca. 95110 (408)437-5254
bright@Data-IO.COM (Walter Bright) (09/06/90)
In article <1845@cs.rit.edu> jeh@cs.rit.edu writes:
<I have always used ".H", to go along with ".C". I have never thought of
<a reason why this would be bad.
On operating systems that are case-insensitive about filenames, ".C" and
".H" are indistinguishable from ".c" and ".h".skp@stl.stc.co.uk (Steve Perryman ) (09/07/90)
Im my department we use the following :
.ch = C++ header files
(including non Class declarations such as extern "C")
.cc = C++ definition files
(Class and function definitions)
This is in keeping with the standard C .h and .c convention, and historically
because we use Objective-C and our suffix for Objective-C header files is .oh .
This gives all "C type" files a "consistent name/feel".
Steven Perryman
(skp@stl.stc.co.uk)rdg@virtech.uucp (Roger D. Gough) (09/08/90)
Maybe this would simply add to the confusion, but why not just use '.c' and '.h', and let whoever needs to know look in the makefile (or equivalent) to see how CC is defined, etc. Besides, in another 5 years, nobody'll be using standard C anyway. :-) -- Roger D. Gough +1 703 689 1692 Sequel Technologies uunet!virtech!rdg
sarima@tdatirv.UUCP (Stanley Friesen) (09/10/90)
In article <1990Sep08.094000.10269@virtech.uucp> rdg@virtech.uucp (Roger D. Gough) writes: >Maybe this would simply add to the confusion, but why not just use '.c' >and '.h', and let whoever needs to know look in the makefile (or equivalent) >to see how CC is defined, etc. The big problem with this is when one needs to *mix* C and C++ sources in a single project (as, for instance, in converting from C to C++ on an existing product). In this case the *single* makefile needs to be able to tell for each source file whether it is C or C++ to call the right compiler. (And due to differences in the semantics of prototypes, the correct compiler must be called) ---------------------------- uunet!tdatirv!sarima (Stanley Friesen)
jac@sundance.llnl.gov (James Crotinger) (09/11/90)
The problem is that a program might be composed of both C and C++ code and so it may be important for the compiler to distinguish between rules for .c->.o and .cp->.o (.cp or .cc being my favorite choices for C++ extensions). I don't see a problem with retaining .h for C++ header files, aside from name conflicts (String.h and ANSI string.h, for example), but the latter isn't a C++ specific problem. As long as the C++ and C compilers look in the proper places for the C++ and C system include files, having both use .h shouldn't be a problem (and hasn't on either my Sun or my Amiga). Jim -- ----------------------------------------------------------------------------- James A. Crotinger Lawrence Livermore Nat'l Lab // The above views jac@gandalf.llnl.gov P.O. Box 808; L-630 \\ // are mine and are not (415) 422-0259 Livermore CA 94550 \\/ necessarily those of LLNL.
allen@carob.ssc.gov (Mike Allen) (09/11/90)
We follow the Free Software Foundation's recommendations and use .h for header files and .cc for c++ programs. It is easy enough to make .h files work for both C and C++, wrapping them C++ specific stuff in #ifdef __cplusplus ... #endif. -- =============================================================================== Michael E. Allen SSC Laboratory MS-1046 2550 Beckleymeade Ave. Dallas, Texas 75237 (214)708-3031 allen@sscvx1.ssc.gov (Internet) allen@sscvx1 (Bitnet) SSCVX1::ALLEN (DecNet) But those who toiled knew nothing of the dreams of Those Who Planned; And the minds who planned the Tower of Babel Cared nothing for the workers who built it.
steve@taumet.com (Stephen Clamage) (09/11/90)
sarima@tdatirv.UUCP (Stanley Friesen) writes: >In article <1990Sep08.094000.10269@virtech.uucp> rdg@virtech.uucp (Roger D. Gough) writes: >>Maybe this would simply add to the confusion, but why not just use '.c' >>and '.h', and let whoever needs to know look in the makefile (or equivalent) >>to see how CC is defined, etc. >The big problem with this is when one needs to *mix* C and C++ sources in a >single project (as, for instance, in converting from C to C++ on an existing >product). In this case the *single* makefile needs to be able to tell for >each source file whether it is C or C++ to call the right compiler. If you include a build line for each file (or for each file of either C or C++ at minimum), it doesn't matter that the file endings are the same. This is not as onerous as it sounds, since I find for projects of any size, the set of header-file dependencies for different source files is different, and thus requires at least a dependency line for most files. The nice thing about text editors is that it is simple to add the lines to the make file -- and in any event, you only have to do it once! -- Steve Clamage, TauMetric Corp, steve@taumet.com
noren@dinl.uucp (Charles Noren) (09/12/90)
In article <451@taumet.com> steve@taumet.com (Stephen Clamage) writes: ...some stuff from another person about including general suffix rules to build .o files out C and C++ files. >If you include a build line for each file (or for each file of either C >or C++ at minimum), it doesn't matter that the file endings are the same. That is probably the best way in terms of making self-documenting build environments, but I'm wierd (if you haven't guessed already :-)). I've got a general makefile that looks at source in a directory and the directory name to determine what to build and how to build it. What to build is determined by directory suffix name (e.g., ".edir" for executable, ".ldir" for library, ".odir" for object-module, etc), and the componant to build from is determined from all the source files with known suffixes in the directory (information is also passed from the makefile in the higher level directory on libraries and include directories). In other words, I've got a makefile that knows how to build anything that follows my twisted conventions (I'm lazy, I hate to edit makefiles, and of course this doesn't work on MS-DOS). For me, standardized extensions for C++ files would be nice. Right now I have the minor inconvenience of having the several C++ suffixes in my makefile suffix list and duplicate the "make object from a C++ file" rule for each suffix. -- Chuck Noren NET: dinl!noren@ncar.ucar.edu US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260, Denver, CO 80201-1260 Phone: (303) 971-7930
zmls04@trc.amoco.com (Martin L. Smith) (09/12/90)
In article <451@taumet.com> steve@taumet.com (Stephen Clamage) writes:
If you include a build line for each file (or for each file of either C
or C++ at minimum), it doesn't matter that the file endings are the same.
This is not as onerous as it sounds, since I find for projects of any
size, the set of header-file dependencies for different source files
is different, and thus requires at least a dependency line for most
files.
We use an automatic include-file dependency generator (stolen, I
think, from cake) to scan C source and build a set of dependency-lines
which are <include>d in the makefile. This scheme has the nice
feature that (except we've sort-of broken the generator) it finds
dependencies on system-wide *.h files as well as local ones. The
latter dependencies become important if non-local *.h files <<ever>>
change.
Anyhow, I want to vote against language-independent suffices. The price
is the loss of (to me) too many useful aids (compiler selection, all of
the above jazz about include files, etc) which save me from
1 lots of typing about how to compile whom depending on what
and
2 manually generated makefile text that too easily becomes
obsolete and requires maintenance.
--
Martin L. Smith Amoco Research Center
P.O. Box 3385
zmls04@trc.amoco.com Tulsa, OK 74102
[zmls04@sc.msc.umn.edu] 918-660-4065adamsf@turing.cs.rpi.edu (Frank Adams) (09/12/90)
In article <67782@lll-winken.LLNL.GOV> jac@sundance.llnl.gov (James Crotinger) writes: >I don't see a problem with retaining .h for C++ header files ... I do. I set parameters in my text editor differently for C and C++ files -- in particular, // is a comment token in C++ files but not in C files. So I want a different file type for C and C++ header files.
bright@Data-IO.COM (Walter Bright) (09/13/90)
In article <ALLEN.90Sep11095555@carob.ssc.gov> allen@sscvx1.ssc.gov writes:
<We follow the Free Software Foundation's recommendations and use .h
<for header files and .cc for c++ programs. It is easy enough to make
<.h files work for both C and C++, wrapping them C++ specific stuff in
<#ifdef __cplusplus ... #endif.
I don't see how complex.h or streamio.h could be made to work for a C program
:-) :-)