Everything in .h's and one .cpp?

1) Incase you meant what I think you did: You can''t put functions in header files. However, you can put the function prototype in the header and the body in a source file that you link in with your project.
2) Splitting up your project is good. But a single function per source file is a little overkillish.
3) That method isn''t any slower. However, it may take longer to compile the code the first time; but the recompile time is dramatically reduced.

[Resist Windows XP''s Invasive Production Activation Technology!]

But it would work, I am assuming. I didn''t want to go and split my code up and then have to bring it all back

Thanks. It would be cool if there was a page called "Frequently Asked C++ Questions." When I type it in search engines I just get things like cplusplus.com and stuff.

Maybe I should put all of my functions in one .h. I don''t mind having the prototypes at the top because they are only one line of code and there will not be more than 10.

Thanks.

quote:

---

Original post by Drizzt DoUrden
But it would work, I am assuming. I didn''t want to go and split my code up and then have to bring it all back

---

Just about any project of moderate size is organized as multiple files. The more internal seperation of the ''modules'' of code you write, the better.

[Resist Windows XP''s Invasive Production Activation Technology!]

Also you can''t declare variables in a header file. You can do this in a header file granted the varible is declared globaly in some other cpp: extern int somevar. And making a file for each function is just not very good programming practice. What if your game contains something like 200 functions or more? Thats a butt load of files you would have in your project. Having main() in a file called main.cpp is good though. Thats usually what i do.


-SirKnight

Yeah, I put all of my global variables in one header file. It works fine.

Thanks guys.

------------------------------

"He who fights with monsters should look to it that he himself does not become a monster... when you gaze long into the abyss, the abyss also gazes into you..."~Friedrich Nietzsche

"So quiet, another wasted night, the television steals the conversation. Exhale, another wasted breathe, again it goes unnoticed...." ~ Dashboard Confessional

Putting code or function definations in an #include works fine. It just slows down your compilation if you aren''t using pre compiled headers.

It''s also not consider the ''right'' thing to do, so if you did it in an office or professional setting, your co-workers would probably yell at you about it.

On many compilers, you _must_ put the code for template functions in headers. On gcc, you don''t have to, but you have to make sure that the templates that are used are instantiated in their .cpp file. I haven''t tried that in MSVC.

Functions to be inlined _must_ be in the header.

Personally, I always put code for any setXyz and getXyz in headers so that the compiler can optimise the function call away. I also usually inline stuff like matrix or vector arithmetic. Other than that, I put stuff in .cpp files.

Unless functions are candidates for inlining, where you put them won''t affect the speed of the game. However, putting a lot of unrelated stuff in one .h or .cpp is a bad move because the entire thing will need to be recompiled if you make a small change. The only people I know of that have a seperate file for each function are GNU, and they only do that for libraries.

Since I almost always use OOP nowadays, I have one .h and .cpp for each class. If two classes (Matrix/Vector, Hash/Bucket, whatever) are closely connected, I''ll put them in one file.

For non-OOPish projects, I tend to have one .h/.c for related groups of files. For a game, I might have "render.h network.h model.h physics.h script.h matrix.h types.h and game.h", along with whatever headers I needed along the way to cope with system-specific stuff (like "dx.h opengl.h sdl.h"), and headers that were specific to the game in question ("weapon.h level.h"). The .c files would follow the same scheme.

---

Just Plain Wrong

Yeah, what Mayrel said.

If you are using C++, then there should be a set of .h/.cpp files for each object that you have. That is one object could have 20 variables and 30 methods, but they are all part of one object, so they go in on set of files. An that is for every object. This way, you can also name the files with the object name, making it easier to find things. ie. use long file names.

ps. I know that Java has a bad rap with some people, but you are forced in Java to use a separate file for each public class. At first I didn''t like it when I was learning it, but in the long run, it made me more organized and a gave me a better understanding of OOP structure.

---
Make it work.
Make it right.
Make it fast.

I usually put all my globals in global.cpp and create a header file with "extern var_type var_name" for each one. It''s a pity that VC6 can''t manage it for me (AFAIK).

Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net

I noticed something bizarre.

I wrote a c program (also with SDL) with functions declared in headers. I changed it over to declaring functions in separate modules with only function headers in the header files. After a recompile, the executable went from 10.5 KB down to 9.5KB! I really don''t understand why it happened, but I can promise you I didn''t change anything else between those two compiles.

For the record, that was with the gcc compiler.

This is quite simple. When you defined the functions in the headers, a copy of each function you used in a .cpp was placed into the .o for that module. When you defined the functions in their own .cpp, only one copy of each function is created.

---

Just Plain Wrong

That would be correct, but there was only one object file to begin with - therefore there should only be one copy of each function even in the first case.

Any other ideas? Or should I get my eyes checked or something?

I usually put each object in a single header, with several other headers for utilities, and such like. If I am exporting a class from a DLL, I will separate the class into a header, and a .cpp with the implementation in there.

Z.

I usually just use one .h / .cpp combo for each class, one main.cpp, and maybe some other .h and .cpp files for special defines and miscellaneous functions.

I would use either a global class in which all my global varialbes and functions are:

class My_Globals
{
static int Blah = 5;
static int Foo(){return 0;}
};

or namespaces

namespace My_Globals
{
blah

}