Question

When I create shared libraries, I have a header file (but with no file name extension) in the root of the library source named the same as the library.

So for example, if my library was called libirock.so, then I’d have a file called irock in the project root. This file will include all of the most important headers in the library, so that when the library is to be implemented, all you need to do is use this include line:

#include <irock> // Instead of <irock.h> 

I got the idea from when I saw a compiler warning similar to:

#include <string.h> is obsolete, use #include <string> instead 

Two questions:

1. Is using irock instead of irock.h best practice?
2. Is is correct to use a single header file instead of many headers?

Course of action

Thanks for your answers! From the answers, I’ve decided:

1. Will use <irock.h> instead of <irock>.
2. I will continue to use a ‘primary’ header file.

Answer 1

There is nothing in the standard governing ‘allowed’, ‘prohibited’ or ‘best practices’ regarding extensions for filenames.

Use whichever form you prefer. On some platforms there’s a convenience factor to having an file extensions for registered types.

For what it’s worth <string.h> and <string> are totally different headers. The C++ namespaced equivalent of <string.h> is actually <cstring>.