How to include header files

Does it matter how I import header files? I’ve seen double quotes as well as arrows used.

Does it matter if they’re capitalized a certain way as well? Experimenting around with this, it seems neither matters, but I figure there must be a reason for tutorials doing it the way they do.

Another question is, (coming from Java here), how do I access a class outside the file it was defined in? Say, I have one.cpp and two.cpp.

Like that? In Java you’d just preface a class name with «public.» In C++, wrangling classes seems to be a bit more difficult..

5 Answers 5

Angle brackets in #include directives means the search path is limited to the «system» include directories. Double quotes mean the search path includes the current directory, followed by the system include directories.

The case of the filename matters when your OS is using a filesystem that is case sensitive. It sounds like you might be using Windows or Mac OS X, where filenames are case insensitive by default.

Angle brackets looks for the header in system header directories (e.g. /usr/include ). Quotes is just an absolute or relative pathname, such as /path/to/header.h or ../headers/abc.h .

For accessing classes from other files, just #include the other file with the class. Be sure to structure your program so that no file is included more than once.

First the simple question:

Does it matter if they’re capitalized a certain way as well?

In most cases, includes refer to files, and the compiler should be able to locate the file that you are including in the system. For that reason capitalization matters in all systems where the filesystem is case sensitive. If you want to keep a minimum of portability you should be consistent in the name of the files and the include . (All linux and mac os have case sensitive filesystems by default, in windows you can configure NTFS to be case sensitive also)

Now, does it actually matter how the file is named? No, it does not, as long as you are consistent in the inclusions. Also note that it is advisable to follow a pattern to ease the inclusion.

Does it matter how I import header files?

The standard is not really clear to this point, and different implementations followed different paths. The standard defines that they may be different, as the set of locations and order in which the compiler will search for the included file is implementation defined and can differ if the inclusion is with angle brackets or double quotes. If inclusion with quotes fails to locate the file, the compiler must fall back to process the include as if it had been written with angle brackets.

That implies that if a file is only present in set1, both types of includes will locate it. If a file is present in set2 but not set1 only the quote include will locate it. If different files with the same name are present in set1 and set2, then each inclusion type will find and include a different file. If two files with the same name are present in the common subset of set1 and set2, but the ordering of the sets is different each inclusion type can locate a different file.

Back to the real world, most compilers will include only the current directory in set2, with set1 being all the system include locations (which can usually be extended with compiler arguments) In these cases, if a file is only present in the current directory, #include «a.h» will locate it, but #include will not.

Now, whether that is the common behavior, there are some implied semantics that are idiomatic in C/C++. In general square brackets are used to include system headers and external headers, while double quotes are used to include local files. There is a grey zone on whether a library in the same project should be considered as local or external. That is, even if always including with double quotes will work, most people will use angle quotes to refer to headers that are not part of the current module.

Finally, while no compiler that I know of does it, the standard allows an implementation (compiler) not to produce the standard headers as real files, but process the inclusion of standard headers internally. This is the only case where theoretically #include «vector» could fail to include the definitions of the std::vector class (or any other standard header). But this is not a practical issue, and I don’t think it will ever be.

Include in header files

gives compile time error. However, if I include at top, it compiles correctly. I don’t want to use include statements in headers,though. How can i do it?

7 Answers 7

You must include in this case to be able to use std::string .

The only moment when you can avoid #including a header is when you’re only using references or pointers of the object in your header. In this case you can use forward declaration. But since std::string is a typedef, you can’t forward declare it, you have to include it.

I’m sure you’re trying to follow the advice to try to #include as less as possible, but you can’t follow it in this case.

Including headers in other headers is a completely necessary thing. It’s wise to reduce it as much as possible, but fundamentally, if your class depends on std::string , then you have no choice but to #include in the header. In addition, there’s absolutely nothing wrong with depending on any and/or all Standard classes- they are, after all, mandated to be provided on any implementation. It’s using namespace std; that’s frowned upon.

std::string is defined in the header file in the std namespace. You have to include it.

You can make sure all dependencies are met by including the necessary files in the implementation files before including your other header files, i.e. make sure #include appears on the first line in your implementation file (.cpp) before including your own header file.

This is not exactly best practice. All header files should fulfill their own dependencies, so users of the header file do not need to care about dependencies. At least that is my humble opinion.

You may have heard that it’s unwise to use using namespace std; in a header, which is true because anything including that header is stuck with all of that in the global namespace. Including the header file that you need is perfectly acceptable.

Unfortunately you can’t get around it.

Even if your class definition looked like this:

then there’s still not much you could do, as forward declaring std::basic_string is a pain in the ass. I’m not even going to demonstrate.

Fortunately, although using namespace std in headers is a definite no-no, you can usually get away with #include ing standard headers in your own headers, without worrying about it.

C/C++ include header file order

What order should include files be specified, i.e. what are the reasons for including one header before another?

For example, do the system files, STL, and Boost go before or after the local include files?

10 Answers 10

I don’t think there’s a recommended order, as long as it compiles! What’s annoying is when some headers require other headers to be included first. That’s a problem with the headers themselves, not with the order of includes.

My personal preference is to go from local to global, each subsection in alphabetical order, i.e.:

1. h file corresponding to this cpp file (if applicable)
2. headers from the same component,
3. headers from other components,
4. system headers.

My rationale for 1. is that it should prove that each header (for which there is a cpp) can be #include d without prerequisites (terminus technicus: header is «self-contained»). And the rest just seems to flow logically from there.

The big thing to keep in mind is that your headers should not be dependent upon other headers being included first. One way to insure this is to include your headers before any other headers.

«Thinking in C++» in particular mentions this, referencing Lakos’ «Large Scale C++ Software Design»:

Latent usage errors can be avoided by ensuring that the .h file of a component parses by itself – without externally-provided declarations or definitions. Including the .h file as the very first line of the .c file ensures that no critical piece of information intrinsic to the physical interface of the component is missing from the .h file (or, if there is, that you will find out about it as soon as you try to compile the .c file).

That is to say, include in the following order:

1. The prototype/interface header for this implementation (ie, the .h/.hh file that corresponds to this .cpp/.cc file).
2. Other headers from the same project, as needed.
3. Headers from other non-standard, non-system libraries (for example, Qt, Eigen, etc).
4. Headers from other «almost-standard» libraries (for example, Boost)
5. Standard C++ headers (for example, iostream, functional, etc.)
6. Standard C headers (for example, cstdint, dirent.h, etc.)

If any of the headers have an issue with being included in this order, either fix them (if yours) or don’t use them. Boycott libraries that don’t write clean headers.

Google’s C++ style guide argues almost the reverse, with really no justification at all; I personally tend to favor the Lakos approach.

Linking .h files with .c with #ifdef header guards

im having trouble linking .h and .c files, i’ve also read some threads regarding this problem and all of them is a bit vague and still i can’t fully grasp the concept of it, and im having a lot of linking problems, Say i have b.c and b.h which i will use in a.c, and im confused whether to include b.h both a.c and b.c cuz b.c itself needs to know the structure defined in b.h, i have some function which has its prototype in b.h and is defined in b.c which also use the structure in b.h, im am not including b.h in b.c cuz as what i know b.h is more like an interface to a.c which will use the functions in b.c. Here a more clear example

b.h file

b.c file

a.c file

Executed the command in cygwin: gcc b.c a.c -g

Now the confusing part, i have a linking error wherein when b.c is compiled it can’t detect the structure and the prototypes in b.h. Cuz all i know is that b.h is used to link b.c from a.c but when both .c is compiled it seems that b.c can’t find its strucutre and prototypes,

Why didn’t i include b.h in b.c? Answer: Cuz as what i know, b.h is already included in a.c and when i include it again in b.c, i’ll be doing double inclusions Follow

4 Answers 4

You do indeed need to #include b.h in b.c . Each file is compiled separately before the linker takes over, so it doesn’t matter that you have included b.h in a.c, because b.c is compiled by itself and has no idea about the contents of b.h unless you include it.

Here’s an example of a #include guard

When some_header_file.h is included anywhere, everything in between the #ifndef and the #endif will be ignored if SOME_HEADER_FILE_H has been defined, which will happen on the first time it is included in the compilation unit.

It is common practice to name the #define after the name of the file, to ensure uniqueness within your project. I like to prefix it with the name of my project or namespace as well, to reduce the risk of clashes with other code.

NOTE: The same header file CAN be included multiple times within your project even with the above include guard, it just can’t be included twice within the same compilation unit. This is demonstrated as follows:

Now let’s see what happens when we try to include the above two files. In a single compilation unit:

This generates a compiler error because test2 is not defined — it is ignored in header2.h because HEADER_H is already defined by the time that is included. Now if we include each header in separate compilation units:

It compiles fine and produces the expected output (1 and 2), even though we are including two files which both define HEADER_H.

How do I include a header file located in a specific folder? (C++)

I want to include a specific header file (MyHeader.h) in a C++ project. The solution for my project is located in the folder:

The header file is located in the folder:

I tried the following line of code, but it doesn’t work.

Is there an easy way to include the header file without adding the full path to «Include directories» in the configuration properties?

Thanks in advance for any help. 🙂

3 Answers 3

It will work if the header is in a files folder in the same directory as the current source.

If you’re trying to include a 3rd party library and not your own header, I’d suggest you to save the library headers in a particular path (say C:\Library\headers ). (If there are static libraries put them in some other path like C:\Library\lib ).

1. In your Visual Studio C++ Project, go to View > Other Windows > Property Manager .

1. Double Click on the Project Name. You will see a dialog box like this:

Make sure All Configurations is chosen in the dropdown, if you want the change to be applied to both the Debug and the Release Configurations. Else just choose the Configuration you want the properties to be applied to.

1. Go to VC++ Directories on the left and choose Include Directories in the right, and enter the path(s) in the textbox separated by a ; .

You can also use the drop down and use the Dialog box to add the paths if you’d prefer to browse to each path separately

1. Add the library path the same way to Library Directories
2. Save the changes using the Save button on the Property Manager Pane’s toolbox.

You will then be able to access the header file contained in the directory you added by something like:

This approach will help, because it won’t matter where the headers saved. The header path is not hard-coded.