C++ programming structure
Author
how do people structure their c++ programs,
i just have a main.cpp with a ton of #includes and lots of header files but uses classes and namespaces to keep it organized and reduce nameing collisions,
does anyone bother with extern and mutiple .cpp files or use some other technique im not aware of?
I seldom have any extern in my programs (if at all), but I usually split up my program into several source files to ease the time required to find a file.
I then create an #include skeleton to either emulate a single translation unit or several translation units depending on which way is faster to compile (single units are faster when files are small and not too many).
I then create an #include skeleton to either emulate a single translation unit or several translation units depending on which way is faster to compile (single units are faster when files are small and not too many).
From a technical point of view, having several cpp files allows seperate compilation units (one unit is just one cpp file) and hence avoids recompilation of the entire code for every little change.
Currently I deal w/ approx. 420 classes, and their implementations are hold in own cpp files (or .inc.h files in the case of template classes). The implementation files together count 30.000 lines. Even after stripping the common file head and some includes would left too much lines to be handled in a single file appropriately.
The next thought goes in direction of targetting. My project compiles several libraries, test units, compiler helper tools, and demo programs. There is obviously a need of several cpp files.
Although it could be handled dependent on the project's extent, I have accustomed to follow this way in general. Perhaps the force of building separate units per class in Java has influenced me.
Currently I deal w/ approx. 420 classes, and their implementations are hold in own cpp files (or .inc.h files in the case of template classes). The implementation files together count 30.000 lines. Even after stripping the common file head and some includes would left too much lines to be handled in a single file appropriately.
The next thought goes in direction of targetting. My project compiles several libraries, test units, compiler helper tools, and demo programs. There is obviously a need of several cpp files.
Although it could be handled dependent on the project's extent, I have accustomed to follow this way in general. Perhaps the force of building separate units per class in Java has influenced me.
there are many ways to combat this issue Engineering a structure is easy
The way i would do it is to have header files include that of what they need 'by using oop this is simple since i would have every object class not interface have both a header and source file' i would then have manger which would be global declare externed next will be organizing a name space.
The way i would do it is to have header files include that of what they need 'by using oop this is simple since i would have every object class not interface have both a header and source file' i would then have manger which would be global declare externed next will be organizing a name space.
Quote:Original post by Kaze
how do people structure their c++ programs,
i just have a main.cpp with a ton of #includes and lots of header files but uses classes and namespaces to keep it organized and reduce nameing collisions,
does anyone bother with extern and mutiple .cpp files or use some other technique im not aware of?
The default linkage of any name appearing at namespace level in C++ is extern, so there's really no need to use that keyword in C++.
I have found, over dacades of experience on large projects in a number of languages, that it's best to break the source for your project into an appropriate level of granularity.
For C++, that usually means each class should have its own header file and implementation file (the exception: private implementation classes do not need their own header file). A class interface can include namespace-level functions as well as member functions, and the declaration of the entire interface for a class goes into a single header file. Use forward declarations as much as possible, and make all header files idempotent. Never include more than you need, always include what you need.
Most classes can be grouped into logical namespaces, and files grouped into logical link units which can be treated as either static or dynamic libraries. The final link for a program is just a matter of pulling in the appropriate library. Libraries can be reused for multiple projects.
The guiding principals include the following.
- faster build times mean $$$ savings. This means smaller granularity and looser coupling between modules. My current project takes about 3 hours to build from a clean checkout.
- smaller source files are easier to grok. That means $$$ savings.
- naming files is easier if the name of the file is the name of the class. That makes finding the apprpriate file faster. Time saved is $$$ saved.
As a professional, saving time and money on a project is important.
I most definately use multiple cpp files, even just for the main part of the program:
Soemthing like:
Main.h (boilerplate which only has required stubs, calls functions in App.h)
Main.cpp (boilerplate implementation
Globals.h (extern version of declarations)
Globals.cpp (actual global memory storage)
App.h (prototypes for program specific top-level code)
App.cpp (implementation for program specific top-level code)
So Main.h and Main.cpp don't change much app to app (in fact when I add new flexibility to my Main skeleton it often still works correctly when dropped into older projects - unless I changed the fundamental hooks).
App.h has the same core contents in every project, but includes any needed app-specific headers as well.
along with all the .h(pp) / .cpp file pairs for my classes
Soemthing like:
Main.h (boilerplate which only has required stubs, calls functions in App.h)
Main.cpp (boilerplate implementation
Globals.h (extern version of declarations)
Globals.cpp (actual global memory storage)
App.h (prototypes for program specific top-level code)
App.cpp (implementation for program specific top-level code)
So Main.h and Main.cpp don't change much app to app (in fact when I add new flexibility to my Main skeleton it often still works correctly when dropped into older projects - unless I changed the fundamental hooks).
App.h has the same core contents in every project, but includes any needed app-specific headers as well.
along with all the .h(pp) / .cpp file pairs for my classes
Author
how do you link .cpp other than with extern,
(sorry iv learned most of c++ myself so i may have missed some thing i should know)
for a game im making after taking a course on UML i have tryed to make its structre better but for the game code itself very hight coupling seems like a enevtibility as it's just a natral requirement that almost every in game object can affect every other
(sorry iv learned most of c++ myself so i may have missed some thing i should know)
for a game im making after taking a course on UML i have tryed to make its structre better but for the game code itself very hight coupling seems like a enevtibility as it's just a natral requirement that almost every in game object can affect every other
Quote:Original post by Kaze
how do you link .cpp other than with extern,
Mmm, yeah, I guess you have to use 'extern' with global variables. Which explains why I never use it. There is a one-one relationship between global variables and bugs.
All you need to do is try to write one multithreaded application and you will sign the pledge and swear off of global variables for the rest of your life.
For extern, I only use it in the "globals" situation described above.
As for .h/.cpp pairs, I always use them for class defintions/declarations, except in the case of template classes, in which case I put all the declarations AND definitions in the .h (as necessary). (Yes, you don't HAVE to... See bottom of here)
My .02
As for .h/.cpp pairs, I always use them for class defintions/declarations, except in the case of template classes, in which case I put all the declarations AND definitions in the .h (as necessary). (Yes, you don't HAVE to... See bottom of here)
My .02
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
