I have seen C++ code saved as both .cc and .cpp files. Is there a difference between the two?
The Google style guide seems to suggest .cc, but provides no explanation.
I am mainly concerned with programs on Linux systems.
As with most style conventions, there are only two things that matter:
Those may seem to contradict, but they each have value for their own reasons.
I've personally never seen .cc in any project that I've worked on, but in all technicality the compiler won't care.
Who will care is the developers working on your source, so my rule of thumb is to go with what your team is comfortable with. If your "team" is the open source community, go with something very common, of which .cpp seems to be the favourite.
Great advice on which to use for the makefile and other tools, considering non-compiler tools while deciding on which extension to use is a great approach to help find an answer that works for you.
I just wanted to add the following to help with some .cc vs .cpp info that I found. The following are extensions broken down by different environments (from the "C++ Primer Plus" book):
Unix uses: .C, .cc, .cxx, .c
GNU C++ uses: .C, .cc, .cxx, .cpp, .c++
Digital Mars uses: .cpp, .cxx
Borland C++ uses: .cpp
Watcom uses: .cpp
Microsoft Visual C++ uses: .cpp, .cxx, .cc
Metrowerks CodeWarrior uses: .cpp, .cp, .cc, .cxx, .c++
The different environments support different extensions. I too was looking to answer this question and found this post. Based on this post I think I might go with .hpp and .cpp for ease of cross-platform/cross-tool recognition.
I am starting a new C++ project and started looking for the latest in C++ style. I ended up here regarding file naming and I thought that I would share how I came up with my choice. Here goes:
Stroustrup sees this more as a business consideration than a technical one.
Following his advice, let's check what the toolchains expect.
For UNIX/Linux, you may interpret the following default GNU make rules as favoring the .cc filename suffix, as .cpp and .C rules are just aliases:
$ make -p | egrep COMPILE[^=]+=
COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
COMPILE.cpp = $(COMPILE.cc)
COMPILE.C = $(COMPILE.cc)
(Note: there is no default COMPILE.cxx alias)
So if you are targeting UNIX/Linux, both .cc and .cpp are very good options.
When targeting Windows, you are looking for trouble with .C, as its file system is case-insensitive. And it may be important for you to note that Visual Studio favors the .cpp suffix
When targeting macOS, note that Xcode prefers .cpp/.hpp (just checked on Xcode 10.1). You can always change the header template to use .h.
For what it is worth, you can also base your decision on the code bases that you like. Google uses .cc and LLVM libc++ uses .cpp, for instance.
What about header files? They are compiled in the context of a C or C++ file, so there is no compiler or build system need to distinguish .h from .hpp. Syntax highlighting and automatic indentation by your editor/IDE can be an issue, however, but this is fixed by associating all .h files to a C++ mode. As an example, my emacs config on Linux loads all .h files in C++ mode and it edits C headers just fine. Beyond that, when mixing C and C++, you can follow this advice.
My personal conclusion: .cpp/.h is the path of least resistance.
It doesn't matter which of those extensions you'd use. Pick whichever you like more, just be consistent with naming. The only exception I'm aware of with this naming convention is that I couldn't make WinDDK (or is it WDK now?) to compile .cc files. On Linux though that's hardly a problem.
The .cc extension is necessary for using implicit rules within makefiles. Look through these links to get a better understanding of makefiles, but look mainly the second one, as it clearly says the usefulness of the .cc extension:
ftp://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_2.html
https://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_10.html
I just learned of this now.
Several people saying .cc doesn't stand for anything? It might. C++ started life as "C with Classes".
True that .cc and .cpp are also command names on most Unix systems (c compiler and c preprocessor respectively).
I use .cpp exclusively, but I started on Windows. .cc is more a Unix convention, although I see it less and less even there. GNU make has rules for .cpp so that's probably preferred, it will work by default on both Windows and everything else. On the other hand modern C++ uses no extension at all for headers, I really don't like that. All my projects use .h for header files, and they support both C and C++ as much as possible via extern "C" and testing __cplusplus.
Other file extensions used include .cxx and .C (capital C). I believe Bjarne Stroustrup used .C originally. .cpp is the name of the C preprocessor so it's unfortunate that it was used for C++ as well.
I personally use .cc extension for implementation files, .hh for headers, and .inl for inline/templates.
As said before, it is mainly a matter of taste.
From what I've seen, .cc seems to be more "open source projects oriented", as it is advised in some great open source software coding styles, whereas .cpp seems to be more Windowish.
--- EDIT
As mentioned, this is "from what i've seen", it may be wrong.
It's just that all Windows projects I've worked on used .cpp, and a lot of open source projects (which are mainly on unix-likes) use .cc.
Examples coding styles using .cc:
I've use .C and .h for source and header, respectively. One nice thing with that choice is that, on the command line, its easy to use *.[Ch] to select all of the code files. Using .C could be a problem on case insensitive filesystems, but if you have foo.c and foo.C in the same directory, you deserve what you get anyway :)
As others wrote before me, at the end its what being used by your project/team/company.
Personally, I am not using cc extension, I am trying to lower the number of extensions and not increase them, unless there's a clear value (in my opinion).
For what its worth, this is what I'm using:
c - Pure C code only, no classes or structs with methods.
cpp - C++ code
hpp - Headers only code. Implementations are in the headers (like template classes)
h - header files for both C/C++. I agree another distinction can be made, but as I wrote, I am trying to lower the number of extensions for simplicity. At least from the C++ projects I've worked in, h files for pure-C are more rare, therefore I did not want to add another extension.
.cpp is the recommended extension for C++ as far as I know. Some people even recommend using .hpp for C++ headers, just to differentiate from C.
Although the compiler doesn't care what you do, it's personal preference.
The other option is .cxx where the x is supposed to be a plus rotated 45°.
Windows, Mac and Linux all support .c++ so we should just use that.
Just follow the convention being used for by project/team.
GNU GCC recognises all of the following as C++ files, and will use C++ compilation regardless of whether you invoke it through gcc or g++: .C, .cc, .cpp, .CPP, .c++, .cp, or .cxx.
Note the .C - case matters in GCC, .c is a C file whereas .C is a C++ file (if you let the compiler decide what it is compiling that is).
GCC also supports other suffixes to indicate special handling, for example a .ii file will be compiled as C++, but not pre-processed (intended for separately pre-processed code). All the recognised suffixes are detailed at gcc.gnu.org
.C and .cc seem to be standard for the (few) Unix-oriented C++ programs I've seen. I've always used .cpp myself, since I only really work on Windows and that's been the standard there since like forever.
I recommend .cpp personally, because... it stands for "C Plus Plus". It is of course vitally important that file extensions are acronyms, but should this rationale prove insufficiently compelling other important things are non-use of the shift key (which rules out .C and .c++) and avoidance of regular expression metacharacters where possible (which rules out .c++ -- unfortunately you can't really avoid the . of course.).
This doesn't rule out .cc, so even though it doesn't really stand for anything (or does it?) it is probably a good choice for Linux-oriented code.
Source: Stackoverflow.com