c++ Include (dependency issue)

Started by
3 comments, last by Endar 14 years, 11 months ago
So, earlier I ran into this problem with structs. I started using many of them and suddenly I had two include files than needed each-others structs. However, when I include one in the .cpp the other was blocked from including it later because of the #ifndef. Example: ui.cpp #include ui.h ui.h #ifndef _uih_ #define _uih_ #include main.h //code here #endif main.h #include file1.h #include file2.h... ect. Main.h had linear dependency meaning no file.h had a dependent listed above it. Should I take out the #ifndef and select the includes manually? Although I like the idea of linear dependency it leaves out flexibility. If a more depth example is needed I can provide.
Advertisement
I haven't understood your problem, so can't give specific suggestions but maybe look here for hints Gamedev Article
Innovation not reiterationIf at any point I look as if I know what I'm doing don't worry it was probably an accident.
Ideally, in each header, you would simply forward declare the struct/class type, have a pointer to it in the class that header defines, and then include the extra header in the source file.

Example:
// header Atypedef struct B B;struct A{     // stuff     B* pB;};// header Btypedef struct A A;struct B{     // stuff     A* pA;};


Now, this is completely valid, as the compiler is able to understand a pointer to a class/struct that isn't yet defined as long as it knows that you intend it to be a defined class, that's what the forward declarations are for.

So then in each source file (*.c or *.cpp), you #include the header. So in the source file for class A you include the header for B, and in the source file for B you include the header for A. This is so that when you use the pointers that you have defined in struct A and struct B the compiler will know about the members of each.

So you can get around needing to include other headers, as long as you forward declare the things that the compiler needs to know.

This only works when you have pointers, like I've shown above. This won't work if you try to declare an actual object instead of a pointer to an object. The compiler will fail it because it doesn't know how big the object is supposed to be. But, with the pointer, it knows that a pointer is always 4 bytes.
[size="2"][size=2]Mort, Duke of Sto Helit: NON TIMETIS MESSOR -- Don't Fear The Reaper
Quote:Original post by Endar
But, with the pointer, it knows that a pointer is always 4 bytes.

Except when it's not.
Good point.

@OP: A pointer is usually 4 bytes on 32-bit platforms, and whenever an exe or a library is built, it is always build for a specific platform type (32-bit or 64-bit). You might be able to use 64-bit pointers on 32-bit platforms, I don't know if you can, at least I don't remember seeing it.

So, the compiler always knows the size of the pointer, which allows it to define the class that contains that pointer, whereas it can't properly define a class that contains a member of unknown size.
[size="2"][size=2]Mort, Duke of Sto Helit: NON TIMETIS MESSOR -- Don't Fear The Reaper

This topic is closed to new replies.

Advertisement