Member Avatar for maybnxtseasn

i have a question where i should place #includes in a file?


Here is what i tend to have
example.h
#include <iostream>
#include <string>

example.cpp
#include <iostream>
#include "example.h"

------------------------------------------------

Is This what i want?
example.h
#include <iostream>
#include <string>

example.cpp
#include "example.h"


What should i strive to achieve?
1.) Place all included possible in the .h file needed to compile without error...if wont compile because .cpp is missing includes then place needed includes to compile in .cpp file?

  • 3 Contributors
  • 2 Replies
  • 125 Views
  • 8 Hours Discussion Span
  • Latest Post Latest Post by Narue

Dani AI

Generated

Short answer: make headers self-contained and keep implementation details in the .cpp. This complements the points from : a header should include whatever it needs so that any translation unit can #include it directly without depending on some other file to have already pulled in a header.

Use forward declarations aggressively when a header only needs a pointer or reference to a type. Forward-declare classes or structs to reduce rebuild scope and break include cycles. Do not forward-declare things that require a full definition (member objects by value, base classes, templates, typedefs, enum definitions), and do not forward-declare standard-library types — include the proper std header in any file that uses them by name.

Include-order and build-time matters. A common rule is: include your own header first, then standard headers, then third-party, then other project headers. Including your own header first forces it to be self-sufficient. As warned, pulling many headers into a header can slow builds — use forward declarations, the Pimpl idiom, or precompiled headers for large projects. Tools such as Include-What-You-Use can help find unnecessary or missing includes.

Quick troubleshooting checklist:

  • "Incomplete type" in a header or impl: include the header that provides the full definition where the full type is actually needed.
  • Missing symbols at link time: usually a linker / implementation issue, not a header include mistake.
  • If code compiles only because of transitive includes, add the missing direct include; transitive dependencies are brittle.

Prefer include guards or #pragma once for safety. These practices keep dependencies clear, reduce compile times, and make the codebase easier to maintain.

Recommended Answers

All 2 Replies

Member Avatar for Topi Ojala

Including libraries in your header file is safe, but might get slow if multiple other files include that header file. Try to think where in your code you need what service from what library.

Member Avatar for Narue

Best practice is to include the exact header you need in each file it's needed. For example:

#ifndef EXAMPLE_H
#define EXAMPLE_H

// example.h
#include <string>

std::string foo();

#endif
// example.cpp
#include <string>
#include "example.h"

std::string foo()
{
   // ...
}
// main.cpp
#include <iostream>
#include <string>
#include "example.h"

int main()
{
    std::string s = foo();

    std::cout<< s <<'\n;
}

Note how <string> is included explicitly in each file. This is because std::string is used directly in each file. You could legally leave the inclusion out in main.cpp and example.cpp because example.h already includes it, but that's not best practice because now anyone reading either main.cpp or example.cpp won't know immediately that you're using the std::string class without reading through the code and then diving into the headers to make sure you're including <string> somewhere.

Inclusion guards ensure that regardless of how many times you include a header, it's only really included once for each translation unit. The standard headers also follow this design and are properly idempotent. So don't worry about multiple inclusions causing errors.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.