All those includes
I''ve been working on a bit of a project lately, and now its growing so do the list of includes (29 at this point). At some points in the project the list of includes almost includes everything that''s in the project. Well, not really EVERYTHING, but a lot. My core is one of those places, where all managers, tasks and other thingies are tied together to make the interface.
What''s the best way to manage your includes? Should I include some things incremental (like including vector.h in utils.h) or are these lists of includes normal? I never done such a big project, so I wouldn''t really know.
Any tips are very appreciated!
I acually put all my includes in one header file which I include with my main cpp file. That header file also has some globals and such...
DarkNebula
DarkNebula
Object Oriented design:
for every object have a header file. that header file contains the class decleration and #includes everything that the class needs to compile. each object has it''s own .cpp file that just #includes the header for that class and nothing else.
Functional Design:
break your project into functional groups. each functional group get''s it''s own header file with function declarations and all #includes that the functions defined in the .cpp file need to compile.
in both scenarios every .cpp file only has a single #include which #includes the header file for that .cpp file. also, make sure to wrap each header file with an #ifndef/#define/#endif series to prevent multiple includes or use #pragma once (not sure of the syntax there) if you are using Visual C++.
the main.cpp file (containing your WinMain & other init functions) tends to have more than one #include, since you don''t really need a header for your main.cpp file (that''s a stylistic bias of mine).
-me
for every object have a header file. that header file contains the class decleration and #includes everything that the class needs to compile. each object has it''s own .cpp file that just #includes the header for that class and nothing else.
Functional Design:
break your project into functional groups. each functional group get''s it''s own header file with function declarations and all #includes that the functions defined in the .cpp file need to compile.
in both scenarios every .cpp file only has a single #include which #includes the header file for that .cpp file. also, make sure to wrap each header file with an #ifndef/#define/#endif series to prevent multiple includes or use #pragma once (not sure of the syntax there) if you are using Visual C++.
the main.cpp file (containing your WinMain & other init functions) tends to have more than one #include, since you don''t really need a header for your main.cpp file (that''s a stylistic bias of mine).
-me
Putting all your includes in a single file is a bad idea. It increases the coupling between your files, and any time you make a change to a header file, you''re entire project will have to recompile. It also forces each .cpp file to open all those headers, even if they''re not needed, which increases your compile time.
I put only system headers that aren''t likely to change into a single file, and then tell msvc (this might not work if your not using vc) to use precompiled headers with that file, and include it first in every .cpp. And then, I only include my own headers in the items that need them. Sure, you can end up with lots of includes (if your .cpp needs everything under the sun) but it will help when your trying to sort out dependencies if you ever want to reuse the code.
Mark Fassett
Laughing Dragon Games
http://www.laughing-dragon.com
I put only system headers that aren''t likely to change into a single file, and then tell msvc (this might not work if your not using vc) to use precompiled headers with that file, and include it first in every .cpp. And then, I only include my own headers in the items that need them. Sure, you can end up with lots of includes (if your .cpp needs everything under the sun) but it will help when your trying to sort out dependencies if you ever want to reuse the code.
Mark Fassett
Laughing Dragon Games
http://www.laughing-dragon.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement