Simple classes question (Layout)
Hi, I have noticed in many projects that clases are layed out with their declaration in a header like glGraphics.h and the class functions in glGraphics.cpp.
Is there any reason for this? When I make classes I make a glGraphics.h and put everything in that one file, is this wrong and if so what advantages are there of doing it the other way.
Thanks for your time,
Thomas Szafran
MSN Messenger: Thomas_Szafran@hotmail.com
Personally, I locate the class definition in the header file, and all of the member functions, etc. are placed in the cpp file.
-------------------
The Reindeer Effect
-------------------
The Reindeer Effect
Yea I noticed that on lots of source code I viewed. I was wondering if that is just a personal preference or actually has some type of purpose to it.
MSN Messenger: Thomas_Szafran@hotmail.com
quote: Original post by Tszafran
Is there any reason for this?
Shortens compile time. Each header file included in a source file gets compiled along with the source file (because what the preprocessor actually does is simply subsutitute the header file''s contents at the line where it reads #include "such_and_such.h" (well, there are certain optimizations that can - are often are, automatically - made, but you get the general picture).
quote:
When I make classes I make a glGraphics.h and put everything in that one file, is this wrong and if so what advantages are there of doing it the other way.
It isn''t necessarily "Wrong", but it has its advantages and disadvantages in every situation. If you wish to distribute your code and don''t wish to muddle things up by including implementation alongside declaration, splitting things up makes for a good way to organize things. If you wish to compile your source into either a static or dynamic link library, separating it into header and source files is virtually essential. Plus, any global scope objects defined in a header are redefined in every file that includes that header (yes, even other headers and all files that include them) - unless they''re made static. Finally, separation of declaration and definition (implementation) is the only way to resolve circular dependency.
There''s an article on the topic. See Organizing C and C++ Code, or something like that, in the Articles and Resources section.
Well, there is a small difference.
If you want to have class B in class A, and class A in class B, you cant just include their headers in each others header, because it would cause a circular reference, instead you can include the others header in only one class, while the other should have something like void* or an interface the previous class is derived from, and then you would include it''s header in the cpp file, and access it by typecasting.
If you want to have class B in class A, and class A in class B, you cant just include their headers in each others header, because it would cause a circular reference, instead you can include the others header in only one class, while the other should have something like void* or an interface the previous class is derived from, and then you would include it''s header in the cpp file, and access it by typecasting.
---Quite soon...ICQ: 163187735
In some cases you can get away with that but it''s not always a good idea. It can become a bit of a problem when you start to get dependencies with other object files. The most obvious being any static variable declarations or globals for that matter.
The rules I have developed for myself are:
1. Header files contain only class definitions, forward declarations, other headers files (within exclusion guards), and inline functions. Also, if there are any special interest templates, enums, consts or defines, they go in the .h as well.
2. Code files contain code and any static declarations. Also, depending on the size of the class I''ll either put all the code into one cpp file or break it up.
For example, I have a class that handles file directories - it''s fairly simple.. on file. On the other hand, the game ''kernel'' is sort of a monster, so I broke it into the major pieces of functionality. This will greatly improve your compile times and maintainability of your code. I find a clean, uncluttered class definition to be easier to understand and document (4 months later, when you have forgotten what the hell it was). If you try to jam all your code in there then the clairity suffers.
Hope that helps..
#dth-0
The rules I have developed for myself are:
1. Header files contain only class definitions, forward declarations, other headers files (within exclusion guards), and inline functions. Also, if there are any special interest templates, enums, consts or defines, they go in the .h as well.
2. Code files contain code and any static declarations. Also, depending on the size of the class I''ll either put all the code into one cpp file or break it up.
For example, I have a class that handles file directories - it''s fairly simple.. on file. On the other hand, the game ''kernel'' is sort of a monster, so I broke it into the major pieces of functionality. This will greatly improve your compile times and maintainability of your code. I find a clean, uncluttered class definition to be easier to understand and document (4 months later, when you have forgotten what the hell it was). If you try to jam all your code in there then the clairity suffers.
Hope that helps..
#dth-0
"C and C++ programmers seem to think that the shortest distance between two points is the great circle route on a spherical distortion of Euclidean space."Stephen Dewhurst
Sometimes, for smaller things, I put the class and the implimintation into the same header file.
For the bigger things that can get a bit messy, I split them up. It just seems that it is easier to fix.
It''s all you need
For the bigger things that can get a bit messy, I split them up. It just seems that it is easier to fix.
It''s all you need
quote: Original post by Maverick the divider
Well, there is a small difference.
If you want to have class B in class A, and class A in class B, you cant just include their headers in each others header, because it would cause a circular reference, instead you can include the others header in only one class, while the other should have something like void* or an interface the previous class is derived from, and then you would include it''s header in the cpp file, and access it by typecasting.
Don''t include files just to declare a pointer to a class.
a.h:
class B;
class A {
B *b;
...
};
b.h:
class A;
class B {
A *a;
...
};
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement