C/C++ filenames

Posted by Samson on Sat 05 Aug 2006 10:36 PM — 4 posts, 19,315 views.

USA #0
Quote:
However a quick test seems to show that compiling a .c file with g++ does in fact treat it as C++. However as Ksilyan says, if they are C++ files, why not have them suffixed .cpp?


Didn't want to continue hijacking the other thread. Given that g++ doesn't care what the filenames are and will in fact compile them properly, what other compilers require this change to be done?

I understand the argument that it should be done because it's considered a standard of some kind, but how or why did this become necessary?

The main reason I didn't do this in my case ( although I have now ) was because I didn't want to have a giant file renaming commit sent to the SVN repository. And it just worked. Even in Dev-C++ it just worked. So I never really figured on bothering.

Also related, would it be necessary to do the same for the H files? I've seen some scattered instances where header files are named as *.hpp and wondered why someone would do that too.
USA #1
g++ is a frontend for gcc that uses a different spec file. That g++ compiles .c files as C++ would be dependent on the spec options which are set by the gcc packager, thus are platform dependent (that is they may well be different between SUSE and Debian for example).

The man page on gcc lists the default automatic detection. However that doesn't necessarily mean that you can successfully invoke gcc to compile C++ source because sometimes the location and search order of system libraries is different between spec files for g++ and gcc.

Pick one or the other. I guess it depends on the purpose of having source around that's both C and C++ compatible. Using C++'s better type-checking is the only one I can think of, but once it's C++ compatible, I'd drop using C unless you are supporting a platform that doesn't have a C++ compiler.
Amended on Sun 06 Aug 2006 02:21 AM by Jon Lambert
Australia Forum Administrator #2
My inclination is to "go with what works".

However, every now and then I get obsessive about doing it properly. :)

Technically, C and C++ are different languages, as I showed with the example before of how C++ lets you have multiple functions of the same name (with different arguments) and C doesn't.

Personally I think it confusing to have the same suffix (.c) for both C and C++ files, it would be like have .pl suffixes for C++ programs, even if you can get it to work it would be confusing.

As for the SVN repository, I feel your pain on that, it is the same in CVS. You could always start a new project "C++ SMAUG" or something. If you have to delete and re-enter every file anyway, there isn't much point in going with the same same repository.

The .hpp files I think have a slightly different meaning. My understanding is that they are for files with templates in them. (Like the STL templates).

Template declarations are a bit funny, since they have to be instantiated for each use (eg. vector<string> or vector<int>), then the implementation (and not just the declaration) has to be available to each compilation unit. I think that is what .hpp files are for - something that is included in every file (that needs it) but is more than just stuctures etc., it includes the implementation for templates. I might be wrong.
Amended on Sun 06 Aug 2006 06:59 AM by Nick Gammon
USA #3
SVN actually handles renames a whole lot better than CVS does. Most importantly it preserves file history over renames, whereas CVS loses it all. To save history in CVS you need to go into the repository and move around the ,v files manually.

My understanding about .hpp is similar to Nick's; it's used for header files that contain implementation details. That being said, I'm not sure if you actually need to make the implementation visible to all people who use it; at work we've been using Sun's C++ compiler and it seems that we just need to instantiate the templates explicitly in some .cpp file that gets compiled into a .o file, that the compiler uses to link in your template instantiation.