🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Source code separation
Author
I''m having problems getting my code separated correctly into different source files and header files. Most of the books I have just skim over this topic quickly and just say you can''t define a declaration more than once. Seems easy enough. However I still end up with all sorts of weird errors which are most likely being caused by including something twice somewhere and its driving me mad. Can someone give me a general set of rules for doing this. Here is the way I''m trying to set up my game:
I have a structure and prototypes for my sprite in my sprite.h and the definitions in sprite.cpp . Do I need to declare the sprite object in the header or both? I''ve found I have to #include in order to recognize NULL in the definitions.
I have a DrawWrapper.h that holds my DD wrapper function prototypes and the definitions are in the DrawWrapper.cpp.
This is where most errors seem to pop up. Just not sure why.
I''ve included ddraw and dinput here.
Then I have my main.cpp that makes the calls to the functions in each and I''ve included DrawWrapper.h and Sprite.h. Since Sprite.h contained windows.h I shouldn''t have to include this also correct?
Man is this frustrating. Meantime, I''ll be studying up on my 3D math. Anyone know if any of the new Immediate mode books are out yet? Thanks!
Still Learning...
Here''s my general rules for header/source files:
1) Header files expose interfaces. Source files implement the interfaces.
2) non-helper structs, classes and functions are all declared in header files.
3) global variables are declared in header functions with the extern keyword. Then they are declared in the corresponding source file without the extern keyword.
4) use preprocessor macros to wrap your header files. i.e. #ifndef / #define / #endif
5) if you use it, include it''s header file. That way if your header dependencies change, you don''t have to change your included headers on all the files.
6) if in doubt, use forward class declarations.
I''ve never had a problem using these rules with sepeartion of code segments. Of course, we''d probably need to see your error messages to give you more help.
1) Header files expose interfaces. Source files implement the interfaces.
2) non-helper structs, classes and functions are all declared in header files.
3) global variables are declared in header functions with the extern keyword. Then they are declared in the corresponding source file without the extern keyword.
4) use preprocessor macros to wrap your header files. i.e. #ifndef / #define / #endif
5) if you use it, include it''s header file. That way if your header dependencies change, you don''t have to change your included headers on all the files.
6) if in doubt, use forward class declarations.
I''ve never had a problem using these rules with sepeartion of code segments. Of course, we''d probably need to see your error messages to give you more help.
SiCrane's rules seem just fine. For your problem, his 4th rule seems most important. For example, in your sprite.h file, do this...
#ifndef SPRITE_H
#define SPRITE_H
... Everything else goes here ...
#endif
Do this for all your header files. As far as the windows part goes, remember that precedence counts when you include your files. Inside your source files, always include your system files before your application files. This way, you don't have to start putting includes in you header files. I normally do something like this.
// Include Windows Headers
// Include DirectX Headers
// Include Application Headers
This should really help clean up your code and add a few years back to your life.
As far as the books go, the one I am looking forward to is Inside Direct3D, but it doesn't come out until March 1, probably just long enough to get out of date.
Edited by - I-Shaolin on 1/17/00 7:53:50 AM
#ifndef SPRITE_H
#define SPRITE_H
... Everything else goes here ...
#endif
Do this for all your header files. As far as the windows part goes, remember that precedence counts when you include your files. Inside your source files, always include your system files before your application files. This way, you don't have to start putting includes in you header files. I normally do something like this.
// Include Windows Headers
// Include DirectX Headers
// Include Application Headers
This should really help clean up your code and add a few years back to your life.
As far as the books go, the one I am looking forward to is Inside Direct3D, but it doesn't come out until March 1, probably just long enough to get out of date.
Edited by - I-Shaolin on 1/17/00 7:53:50 AM
Ok I realize that this is probably a major newbie question but I''ve always wondered why can''t just put your functions in header files and include them that way. I link the objects together like everyone else but only because that''s the only way I''ve ever seen it done and I''ve always wondered the reason behind it.
This is the thing: In C/C++, you can call a function as long as it has been declared before you call it, even if it wasn't implemented before you call it. So all you need to put in header files is the declaration of the function, hence the name "header". The reason you can't put the function implementation in the header (unless it's declared as "inline") is because when the program is compiled, it is only needed to have one copy of the function in the executable files (and the obj files). So you compile the function, and it gets stored in only 1 obj file. Then, when you link all the obj files together into an exe or dll or lib or whatever, that file is just a collection of all the functions and variables in the obj files (and, therefore, the source files), and the WinMain or main gets called first. So, to answer the question, the reason you can't implement the function in the header is because there has to be only one copy the the function in the exe file, while the declarations are required to use the functions in the code. After you use the language for a while you'll start to understand it more.
------------------------------
Jonathan Little
invader@hushmail.com
http://www.crosswinds.net/~uselessknowledge
Edited by - Qoy on 1/17/00 11:36:15 PM
------------------------------
Jonathan Little
invader@hushmail.com
http://www.crosswinds.net/~uselessknowledge
Edited by - Qoy on 1/17/00 11:36:15 PM
Author
Thanks everyone! SiCrane, I think you hit it on the head with the Macros! I''ll go give that a shot because I was getting errors saying so-&-so wasn''t declared/defined when I know damn well it was. I might have missed the extern on my globals. Should the prototypes have "extern" also or will it matter? I''ll keep playing. Thanks a lot though! Once I get this working it will be sooooo much easier to find what I''m looking for rather than sifting through all of my code in one file 
Still Learning...
Still Learning...
Don''t extern you''re function prototypes.
Well, if some of your functions are coded in C and the other''s are coded in C++, the C++ functions need to see the C function prototypes wrapped in an extern "C" block. (If you''re wonder why that''s so, it''s a hint to the linker on how to expect the obj/lib files to look. sort of.)
ex:
#ifndef __SOMEHEADER_H__
#define __SOMEHEADER_H__
#ifdef __cplusplus
extern "C" {
#endif
void function1(int blah);
...
void function967(int blah);
#ifdef __cplusplus
}
#endif
#endif
Remember that only if your functions are coded in a .c file and you expect to use the functions in a .cpp file. IMO, it''s just easier to code everything in one or the other.
Well, if some of your functions are coded in C and the other''s are coded in C++, the C++ functions need to see the C function prototypes wrapped in an extern "C" block. (If you''re wonder why that''s so, it''s a hint to the linker on how to expect the obj/lib files to look. sort of.)
ex:
#ifndef __SOMEHEADER_H__
#define __SOMEHEADER_H__
#ifdef __cplusplus
extern "C" {
#endif
void function1(int blah);
...
void function967(int blah);
#ifdef __cplusplus
}
#endif
#endif
Remember that only if your functions are coded in a .c file and you expect to use the functions in a .cpp file. IMO, it''s just easier to code everything in one or the other.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
