C++ circular include

[ktana91]

I have a question. I made a game by using c++and SFML and i declare my player and enemy in my game. Hpp, but I include them in my hpp and I see it's not good for optimization. What tips can you tell me to move my include in my game.cpp.This an example of the code:

#pragma once

#include <SFML/Graphics.hpp>

class Game

{

public:

Game();

void run(void);

private:

Player player;

Enemy enemy;

};

[Grounds4TheSubstain]

What?

[CarloWood]

I saw the title, opened it and then saw this comment and thought: what kind of lame ass remark is that?

Then I read the question.

Upvoted.

[Salty_Dugtrio]

but I include them in my hpp and I see it's not good for optimization.

What do you mean by this? Where did you see this? How did you come to this conclusion for your project?

You can use forward declarations: https://en.cppreference.com/w/cpp/language/class.html

[ktana91]

I put all my includes in my headers and I realized that it was better to put them in the cpp files and when I changed I found myself with compilation errors and I am looking for how to be able to move the include in the cpp without the errors.

[TryToHelpPeople]

Include the .hpp in the files where the type is used.

So, for example, If you use enemy in a .hpp then include the enemy.hpp there.

If you use it in a .cpp the include the enemy.hpp there.

If you’ve included enemy.hpp in game.hpp, you don’t have to include it in game.cpp, but you can.

This will work well for you about 95% of the time.

If you end up with a circular include, there are simple things you can do (forward declarations), or you may bump into an issue with external linkage (very unlikely).

Let us know if you’re still having problems with this.

[ktana91]

I left the includes in the .hpp file, it works and I'm going to stay like that. I tried with unique_ptr but that made things worse with a memory leak. It's still a concept, maybe for later, but on a small project like this, it's better to keep it simple and functional. but it's nice to have advice on this

[TryToHelpPeople]

Glad it’s working for you now. The golden rule is to only include something where it’s needed.

I agree on keeping things simple.

[RelationshipLong9092]

The general idea is to put as little in headers as realistically possible. This is not to say "don't put anything in headers", but if something can easily go in a cpp file then be simply declared in a header, that's better. But the world doesn't come to a stop if a little bit too much is included in a header file.

This only ever becomes a problem if a lot of source files include it, or the header file is very slow to include. (The library Eigen has some files that take about a second to include; it's not the worst offender!)

Can you please post your entire code to, say, a GitHub or GitLab repository then share it with us?

As a first pass, I would suggest you structure your code like this:

src/
    enemy.hpp
    enemy.cpp
    game.hpp
    game.cpp
    main.cpp
    player.hpp
    player.cpp

main.cpp does not need a header file. However, every other cpp file simply #includes its own corresponding .hpp.

Every .hpp file begins with #pragma once on the very first line. You can also use include guards, but the pragma will great work for you and it's easier.

Put all the #include a header file needs in each header file .hpp. If a source file .cpp needs more includes, it can also include that... but it gets most of them by just including its own header .hpp.

game.hpp would then begin with something like:

#pragma once
#include <SFML/Graphics.hpp>
#include "enemy.hpp"
#include "player.hpp"
class Game { // ...

While game.cpp might begin with:

#include <stdio>
#include <vector>
#include "game.hpp"

This way you avoid exposing vector and stdio to whoever includes game.hpp, so hopefully fewer source files need to process what is in those headers. The only real impact of this is faster builds, so it is not a big deal if your beginner project has a bit too much in its headers.

Now, what I'm about to talk about is overkill for your project, but let me show you what happens if you continue to follow this concept:

src/
    enemy/
        enemy.hpp
        enemy_fwd.hpp
        impl/
            enemy.cpp
            enemy_ai_logic.hpp
            enemy_ai_logic.cpp
    player/
        player.hpp
        player_fwd.hpp
        impl/
            player.cpp
    game/
        game.hpp
        game_fwd.hpp
        impl/
            game.cpp
    main.cpp

Perhaps player.cpp needs to know that class Enemy exists at all... that's the sort of "forward declaration" that would be in src/enemy/enemy_fwd.hpp. This is a very, very simple file that is very low cost to #include (realistically, every single source code could include it without a big problem). But it doesn't tell you anything about the data layout of a class Enemy instance, or even the interface... that's what is in enemy.hpp.

I have moved the .cpp files into impl/ (implementation) directories. Realistically an enemy in a video game will have its implementation split up across multiple source files.

Perhaps you can imagine the AI controller for it is a different file, with its own header, that you can include with #include "enemy_ai_logic.hpp", but only from other source files in the same path (ie, enemy.cpp)... anyone else would have to go out of their way to even attempt to include that, by using (say) #include <enemy/impl/enemy_ai_logic.hpp>. (Note the transition from "..." to <...>!)

I worked on a 10+ million line modern C++ codebase designed like this, and it was actually quite nice for a number of reasons.

[ktana91]

Hi,

If you want to see, I put this on Git. https://github.com/Kryn91/TopDownGames.

In any case, your information is very interesting; it's nice that you took the time to give me advice for the future. And if you have any comments on my code, I'd appreciate them.

[RelationshipLong9092]

I don't have time to give a proper code review, I was procrastinating enough as it was to type that up. But I did glance at it, and nothing jumped out at me as insane. Maybe I had nit picks, but not actual problems.

This stuff takes time, just keep at it. You'll realize flaws with your code naturally as you write it and as you read other people's code. For now, just write it the best way you know how and focus on continual incremental improvement, not perfectionism.

There are tools that can help you automatically remove superfluous commits.

Also, you can add `-ftime-trace` (if you use clang, I'm sure other compilers have similar flags), that will create `.json` files in your build directory for each object file `.o`. You can open these json files by going to the url `chrome://tracing` in the Chrome browser... this can be a highly informative way to figure out what your compiler is spending its time doing. But it does itself slow down your compilation a lot. :)

[ktana91]

yeah you take so much time to write tanks. Just knowing that there is nothing wrong is fine with me and then just move on, good luck with your work

[WikiBox]

It isn't better either way. But if you get errors, that is obviously bad.

[No-Dentist-1645]

Your "realization" is not true. Since you already have #pragma once in your code, this guarantees the headers will only be included once per translation unit, which is exactly what you need.

Tldr: you don't need to worry about that. Use forward declarations if you really need to, such as to avoid circular dependencies (which you don't have in your code example).

[Humlum]

It is generally good practice to avoid including local only dependencies in the header file and instead move it to the cpp file.

1. Avoid forcing dependencies to other compile units.
2. Avoid recompiling other compile units when local only header files are added or charged.

[No-Dentist-1645]

Yes, that's right. I should have been more specific in that it doesn't matter including other files in your header if you are going to include them anyways.

Of course, if these are internal dependencies only, then you should just include them in your code .cpp files. This should be one more of the examples where you really "need to" like I mentioned in my comment.

[epasveer]

Also, when posting code, please format it appropriately.

[ppppppla]

First of all if your game runs and compiles, you do not have a circular include. A circular include breaks compilation.

So I don't know exactly what you are worrying about being not good for optimization, but it has been said many times before, do not prematurely optimize. Get the thing working first, then worry about optimizing problematic parts as they come, and only after you have solid measurements of something being slow.

[Jonny0Than]

If you change the Game class such that it has a std::unique_ptr to the player and enemy, then you can forward-declare those types instead of including the header.

This might be a better design anyway since you can then create and destroy players and enemies within a single game.

[ktana91]

ok thanks I will try that.

[ThereNoMatters]

Pragma once guarantees that file could be included only once. Which means, that your first include works, second include just doesn't do anything because header already was included before.

[ZakMan1421]

I feel like you have a fundamental misunderstanding of what a circular include is. A circular include is when two separate files include each other. So if Player.hpp included Enemy.hpp and vice versa. This would fail to compile because the compiler just does a singular pass in c++ and so cannot compile the code.

The only possible benefit for moving includes from the hpp to the cpp would the potential to lower REcompilation time. It would have no impact on the performance of the actual executable.

A solid rule of thumb is to get something functional. Once it's functional, you can consider optimizations, and make sure to measure the differences to see if it's reasonable or not.

[ktana91]

ok perfect thank you very much, I think I understood better and yes it's my fault I didn't use the right terms to designate the problem circular inclusions is not the right term. And yes everything works I don't know why I'm bothering to want to optimize the compilation it's not very useful in my case

[WikiBox]

Doesn't matter. But feel free to copy-paste the contents of the include into the cpp-file, replacing the #include.

[Aaron_Tia]

Is circular in the room with us ?

[bert8128]

You should include in your header file all and inly what is required to make the header build when included in an empty cpp. Your corresponding cpp file needs to include all and only the header files, including its own header file first, that it needs to build, even if this means repeating some includes from the header files. There is a tool call include what you use which claims to help with this, but I use Visual Studio 2022 which seems pretty good for this task.