   Problem organizing headers...
  I'm having trouble getting my headers and multiple source files organized with C++. Here's how I'm breaking it down:constants.h // Declare constantsclasses.h // Declaring classesfunctions.h // Prototyping my functionsmain.cpp // Main functionfunctions.cpp // General functionsclass1.cpp // class2 functionsclass2.cpp // class1 functionsI'm including '#pragma once' at the start of every header. I'm having trouble getting everything to "mesh" together.For example:There is an object I need to use globally. Many of my functions such as gameloop() and gameinit() need to use it. However, if I try to 'extern Class object' in my constants.h file, it doesn't know what the 'Class' is. But if I include the classes.h file first, then the classes.h can't use any constants.I tried a "master include" file and included that in everything to no avail.I also just tried creating the object at the end of my class declaration. But that just throw an error of "_object already defined" at the '{' of my main() function. And there is no other location it's defined. I'm guessing this is because it's in a header file.If I move the class declaration into my class1.cpp with its functions, then the compiler still throws errors when reading over my other functions because it hasn't seen the class1.cpp yet.Any ideas? I'm guessing there's a few subjects I need to look up to understand this.   
  Are you wrapping all of your files in ifndef/define/endif?#ifndef _MY_HEADER_H#define _MY_HEADER_H...header contents...#endif#pragma is Microsoft compiler-specific and isn't the best for this kind of stuff.What you want to look into is idempotency;  Seems I've partly solved my problem by creating a globals.h that "extern" all my globals, that comes after the constants.h and classes.h are called.Problem was with my trying to declare globals in my constants file. So there were headers that both needed each other.Am I going about the best way to do this? Seems there would be a simpler way. Why have 2 filetypes .h and .cpp? Seems it would be easier to simply include other source files into one source file.Quote:#pragma is Microsoft compiler-specific and isn't the best for this kind of stuff.What you want to look into is idempotencyHmm, seems I should use the #ifndef method instead considering I'd also like to compile on linux. Thanks.   ;  Generally, I like to include the separate header files in each of my source files and use them as needed.Wrapping your headers in #ifndef/#define/#endif will solve the headers including each other problem.Including a header actually means that the compiler will copy the contents of the included file to the line that you included it from, so if you have a globals.h which includes everything else then you're unnecessarily bloating your .cpp file. Globals can be useful, yes, but in this way they can be a pain. If you need a global, try to keep it in the header that it's relevant to, and include it if necessary.By the way, file extensions don't mean anything, only the contents do. You can include a .cpp or .h, even a .exe. They're just there for easy reference and sorting. Headers exist for making definitions for your functions, cpp files exist for actually defining the contents of the functions.   ;Quote:#pragma is Microsoft compiler-specific and isn't the best for this kind of stuff.It seems that it is also supported in gcc (from wikipedia):"GCC originally gave a warning declaring #pragma once "obsolete" when compiling code that used it. However, with the 3.4 release of GCC, the #pragma once handling code was fixed to behave correctly with symbolic and hard links. The feature was "un-deprecated" and the warning removed."   ;Quote:Original post by desolatordanProblem was with my trying to declare globals in my constants file. So there were headers that both needed each other.Generally speaking, you don't need this sort of 2 way dependency. You can almost always get rid of it. Part of the problem is almost certainly because you wanted to use an arbitrary pair of files instead of breaking them up further according to responsibility. In this case, trying to combine global instances of classes with constants is your problem. If you had separated these out, you could have had a globals.h, which included a classes.h, which included a constants.h, and it would have been fine. The further you split things up, the smaller the dependencies become.Of course, if you had no globals, this problem wouldn't exist anyway...Quote:Why have 2 filetypes .h and .cpp? Seems it would be easier to simply include other source files into one source file.The way that C++ is compiled generally makes that impractical.   ;Quote:Original post by KuraitouIncluding a header actually means that the compiler will copy the contents of the included file to the line that you included it from, so if you have a globals.h which includes everything else then you're unnecessarily bloating your .cpp file...Actually, the bloating isn't an issue.  Presumably all the header files will be needed at some point, so they all must be included.  Once a header file is included, it won't be again due to the #ifndef/#define/#endif include guards.  So whether he includes everything in globals.h or includes them in different files, it won't cause the header to be copied over and over again.Quote:Quote:Why have 2 filetypes .h and .cpp? Seems it would be easier to simply include other source files into one source file.The way that C++ is compiled generally makes that impractical.Not to mention the benefit of organization that header files can bring to a project.  Of course, I guess you could just name them with a .cpp extension, but then you've kind of missed the point...;Quote:Original post by bschneidActually, the bloating isn't an issue.  Presumably all the header files will be needed at some point, so they all must be included.  Once a header file is included, it won't be again due to the #ifndef/#define/#endif include guards.  So whether he includes everything in globals.h or includes them in different files, it won't cause the header to be copied over and over again.I don't know what optimizations the compiler makes, but I would assume that in large projects with large headers it will take slightly longer to compile.   ;  Every translation unit is compiled, and thus assembled, in isolation. So include guards and the like don't make you include the file only once -- they make you include/copy/process the file only once per source file that uses it (or at least behave as such).   