number of sections exceeded object file format limit: compile with /bigobj

[rudiHammad]

Hello,
as my ecs components and system grows, i just got today the error I wrote in the title.
Doing some research I read that it is because I might be including entt.hpp, which is a hug file, in a lot of places in my code.
The current fix in visual studio was to go into the c++/command Line (with all options set) and add /bigobj
So my question is. Is this normal or I am really messing up my code?

I am not an expert on how compiliers and linkers work. My understanding is very basic in that regard, so as far as I know, at compile time all includes are copy/paste in the respective files that use them. The result is know as a translation unit that is then compiled into a .obj. So each translation unit becomes a .obj. And finally, the linker does its magic with all the .obj cleaning up all the duplicate code.
I have no idea if anything that I said is accurate, but that at least my basic knowledge.

I will start to check if I can get ride of some entt.hpp includes, but I don't think I can. I always though it was safe to include as required and trusting the compilers to do the clean up.
Any advice? Should I just be happy with the fix adding /bigobj in the command line or should I thing over my code?

thanks

[Green-Sky]

This is relatively normal for cpp, depending on the code.
There are two major things that make cpp code large.
(Machine-)Code duplication due to templating. Every used and defined type for a template gets generated. This is usually just an intermediate step, as compilers/linkers can optimize unused code etc away.
Long symbol names, compounded by the duplication of the prev point, results again in large symbol tables and humongous debug sections/files. At least msvc compresses debug info by default...

[rudiHammad]

Ok, good to know.
I started removing a lot of #include "entt.hpp" from many .cpp and .h files, and everything is still working. In some cases, I am not sure why it works, but I guess that's because it was set in any of the other included files I am using. My problem with this is that I have to keep track of where it is coming from.
What about forwarding something like:

namespace entt
{
    entity;
    registry;
    ....
}

I tried that but I don't know it is actually working because of it, or just because the entt.h is coming from somewhere else already.

[Green-Sky]

Using bigobj is fine. But you can reduce the symbols by being selective about including. You don't need to include the full entt.hpp, look into entt.hpp and see which parts of entt you actually need and include that.

[rudiHammad]

You don't need to include the full entt.hpp, look into entt.hpp and see which parts of entt you actually need and include that.

In Python, you can do something like from someModule import whatEver. I didn't know you could do something similar in C++. Can you explain a little bit what you mean by that? Do you mean using a forward declaration? using extern maybe? I am not sure what you mean otherwise.

[Green-Sky]

The #include directive that c++ inherited from c copy pastes the contents of the file at the place #include is called.
Right next to entt/entt.hpp there is also entt/fwd.hpp which provides forward declarations. Then, there are all the subfolders with specific features that you might be using.

https://github.com/skypjack/entt/tree/master/src/entt

Here is the top level entt.hpp, as you can see it includes all the files in the subfolders. Instead you can include eg: entt/entity/registry.hpp if you are mostly using just the ecs part.
Also take a look at the entt/fwd.hpp, it itself includes a buch of forward declaring files in the subfolders, so you probably don't need them all.

[skypjack]

Yeah, exactly, you don't have to forward declare things on yoursefl in EnTT. They're pretty all much available already in a fwd.hpp file. If anything is missing, just let me know. 🙂

[rudiHammad]

awesome, thank you both.