When can you omit the file extension in an #include directive?

Question

I'm playing around with gmock and noticed it contains this line:

#include <tuple>

I would have expected tuple.h.

When is it okay to exclude the extension, and does it give the directive a different meaning?

Answer 1

If the file is named tuple then you need to #include <tuple> if it's named tuple.h then you need to #include <tuple.h>

It's as simple as that. You are not omitting any extension.

Answer 2

It's including a file that is simply named "tuple" -- the file itself lacks an extension.

The putative standard for C++ include files is to name them without the .h extension; many library writers follow this standard (STL,etc) but some do not.

Answer 3

My understanding was that #include tuple would "point" to tuple.h.

Check this out: iostream vs iostream.h

Answer 4

The C++ standard headers do not have a ".h" suffix. I believe the reason is that there were many, different pre-standard implementations that the standard would break. So instead of requiring that vendors change their exiting "iostream.h" (for example) header to be standards compliant (which would break their existing user's code), the standards committee decided that they'd drop the suffix (which, I believe no then existing implementation had already done).

That way, existing, non-standard programs would continue to work using the vendor's non-standard libraries. When the user wanted to make their programs standards compliant, one of the steps they would take is to change the "#include" directive to drop the ".h" suffix.

So

#include <iostream>     // include the standard library version
#include <iostream.h>   // include a vendor specific version (which by 
                        //      now might well be the same)

As other answers have mentioned, writers of non-standard libraries may choose either naming convention, but I'd think they would want to continue using ".h" or ".hpp" (as Boost has done) for a couple reasons:

1. if & when the library gets standardized, the standard version won't automatically override the previous, non-standard one (causing broken user code in all likelihood)
2. it seems to be a convention (more or less) that headers without a suffix are standard libraries, and those with a suffix (other than the old C headers) are non-standard.

Note that a similar problem happened when the committee went to add hash maps to the STL - they found that there are already many (different) hash_map implementations that exist, so instead of coming up with a standard one that breaks a lot of stuff out there today, they are calling the standard implementation "unordered_map". Namespaces were supposed to help prevent this type of jumping through hoops, but it didn't seem to work well enough (or be used well enough) to allow them to use the more natural name without breaking a lot of code.

Note that for the 'C' headers, C++ allows you to include either a <cxxxxxx> or <xxxxxx.h> variant. The one that starts with 'c' and has no ".h" suffix put their declarations in the std namespace (and possibly the global namespace), the ones with the ".h" suffix puts the names the global namespace (some compilers also put the names in the std namespace - it's unclear to me if that's standards compliant, though I don't see the harm).

Answer 5

There is nothing special going on. The file is simply named tuple.

The reason for this...that standard library headers have no file extention are because of namespaces.

Namespaces were added to the C++ standard late in the game with the C++98 standard, including the std namespace that all standard library entities reside in.

When the standard library got moved to the std namespace, that meant that all existing C++ code would break since all of it expected the library to be in the global namespace. The solution was to leave the old "dot-h" header files alone and provide the namespaced library in files that have no extension.

This way, old code that would #include<iosteam.h> could expect a global cout while new code could #include<iostream> and expect a std::cout.

Answer 6

In additional to the fine answers already posted, it should be noted that the C++ standard does not require the directive "#include <iostream>" to read a file named "iostream", or even "iostream.h". It could be named "fuzzball". Or, no corresponding file may exist and the definitions be built into the compiler and activated by the include directive.

Answer 7

Folks,

I think the deal is: #include <lib> allways prepends /lib/include to the search path (the .h is infrerred) whereas #include <lib.h> searches just -I<pathname>.

Please note that I could be wrong... It's just how I think it works (in Forte cc on Solaris).