pal@calmasd.GE.COM (Peter Lawrence) (05/06/88)
Someone asked recently: what should C++ file name extension be? How about using the same extensions as C. The intention of Bjourn Stroustroup as stated in the beginning of his book is that the C++ language is fully upward compatable with C. Users should be replacing their C compilers with C++ compilers. This may not be happening immediately because of various temporary difficulties but it is obviously the direction of the future. Implementors should not be locking users into maintaining two compilers and their associated intricacies with 'make' etc. when one compiler will do. Pete Lawrence. ps. dont flame on me because c++ is only a preprocessor and is handycapped compared to a 'real' C compiler, this is not true, there are real C++ compilers available now, and symbolic debuggers; or because C++ is not truely upward compatable with C, if that is true flame on to Bjourn about it. -- pal@calmasd.GE.COM or ...!sdcsvax!calmasd!pal
djones@megatest.UUCP (Dave Jones) (05/07/88)
in article <2757@calmasd.GE.COM>, pal@calmasd.GE.COM (Peter Lawrence) says: > > > Someone asked recently: what should C++ file name extension be? > > How about using the same extensions as C. Some of your questions have been answered here already. Utilities such as "make" and editors such as "emacs" want to know the form of a file from inspecting its name. I name my files foo.C and foo.H, and emacs does auto-indenting which works for classes, etc. > The intention of Bjourn Stroustroup > as stated in the beginning of his book is that the C++ language is fully > upward compatable with C. Hmm. I haven't got the book handy right now, but did he say just that? C++ is not a superset of C. The way function prototypes are done is essentially different. And C and C++ have different name-spaces. So C++ is not upward compatible with C. > Users should be replacing their C compilers with > C++ compilers. This may not be happening immediately because of various > temporary difficulties but it is obviously the direction of the future. > Implementors should not be locking users into maintaining two compilers and > their associated intricacies with 'make' etc. when one compiler will do. > Users should not be changing things that work. If the program is written in C and it works, don't fix it. The customer will not be impressed with your reasoning when you try to tell him why you switched to a new compiler, when the old one was doing just fine. So far as new work goes, yes I would prefer to do it in C++ rather than C, but some things have to be ported to lots of different machines. I can't afford to go into the porting-C++ business. > ... From the comments I have seen on the net, foo.cc and foo.hh seem to be pretty good choices for suffixes. - Dave Jones
nevin1@ihlpf.ATT.COM (00704a-Liber) (05/07/88)
In article <2757@calmasd.GE.COM> pal@calmasd.GE.COM (Peter Lawrence) writes: >How about using the same extensions as C. The intention of Bjourn Stroustroup >as stated in the beginning of his book is that the C++ language is fully >upward compatable with C. This is not true! It is *almost* a superset, but there are a number of situations where this is not true. Whether C++ can ever be a proper superset of C remains to be seen (especially since C is changing right now). If this were true, then why is there a section in the C++ book about incompatabilities with C (I'd quote some but I have loaned out my book)? >Users should be replacing their C compilers with >C++ compilers. Only if you are conforming to C++ in your C programs. For a lot of existing C code, this extra pass maybe useless, or might even break existing C code. >This may not be happening immediately because of various >temporary difficulties but it is obviously the direction of the future. Maybe. Although the original intention was to make C++ a 'better C', only the future will tell if this goal is still reasonable. >Implementors should not be locking users into maintaining two compilers and >their associated intricacies with 'make' etc. when one compiler will do. The implementors' aren't locking users into anything; it's the people who don't think it's worth converting millions of lines of existing C code just so it will pass the C++ translator/compiler cleanly and w/o error. If you are volunteering to do this task for all of us who have to maintain C code, please let us know. :-) -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
bright@Data-IO.COM (Walter Bright) (05/10/88)
In article <2757@calmasd.GE.COM> pal@calmasd.GE.COM (Peter Lawrence) writes:
<Someone asked recently: what should C++ file name extension be?
<How about using the same extensions as C. The intention of Bjourn Stroustroup
<as stated in the beginning of his book is that the C++ language is fully
<upward compatable with C. Users should be replacing their C compilers with
<C++ compilers.
<ps. dont flame on me because c++ is only a preprocessor and is handycapped
<compared to a 'real' C compiler, this is not true, there are real C++
<compilers available now, and symbolic debuggers; or because C++ is not truely
<upward compatable with C, if that is true flame on to Bjourn about it.
If you have a C++ compiler, you still need a C compiler because:
o C++ is not a true superset. The biggest problem is that struct
tag names are in the same name-space as regular names. This
causes problems in compiling functions that call stat().
o C++ does an awful lot more work than C, and so the compiler
will inevitably be slower than C. There are a lot of applications
where speedy compiles help a lot more than the features of C++
(such as in the case of machine-generated C).
It is important to have a different extension so make can recognize it.nevin1@ihlpf.ATT.COM (00704a-Liber) (05/13/88)
I personally prefer the .cc and .hh extensions. Besides being the most portable and least conflicting of any that have been proposed on the net so far, if the object code ever needs to be distinguished from C object code, the generalization of this would be perfect. Isn't .oo good for C++, an oo (object oriented) language? :-) :-) -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah