My #include problems
Author
Ok, can I start off with saying that I am not sure that I am using the best method for achieving what I want, so if you have an improvement, let me know please !
My problem is in Using C++, and in trying to implement an OO approach to my application.
I have a main application that includes a rules file.
This rules file in turn calls a data class file.
i.e. App -> Rules -> Data Class.
There is a structure in the data class that wants to include a structure in the rules class.
So this means (I think) that when I #include I get a kind of circular reference where the rules include the data, but the data wants to include the rules. How can I resolve this, can I make the data class just accept that I am using a type that is defined elsewhere ?
I suspect that the best answer will be to return to the drawing board, but just out of curiosity, is there another way of achieving this ?
Also, if this is one of those questions that repeatedly appears, then I apologise for asking and isn''t it worth adding to the FAQ ?
Thanks in advance
B.P.
If you're using MSVC, add the following line of code to the beginning of each header file you don't want included more than once:
This tells the preprocessor to include that header file only once.
Edited by - noparity on January 30, 2002 12:42:15 PM
#pragma once This tells the preprocessor to include that header file only once.
Edited by - noparity on January 30, 2002 12:42:15 PM
Don''t use #pragma once. Instead, use "include guards" which do the same thing but work on all compilers:
#ifndef _MYHEADER__H_#define _MYHEADER__H_// everything that would normally go in your header#endif
Hmm, if you don''t do that wierd things do happen. I''ve personally found myself in this problem even using the #pragma once preprocessormajiggy, though. FYI, you could also
#ifndef RULES
#define RULES
... your code ...
#endif
, and you''d not be relying to heavily on one particular compiler.
but that''s not the problem I think you''ve got...
If you include both header files in one of the header files,
// Rules.h
#include "Rules"
#include "Data"
and include that one in both of the source files,
// Rules.cpp
#include "Rules"
...
// Data.cpp
#include "Rules"
I think that''ll keep you from a circular reference, but it''s darn bad style. You might also have to define the class that the other depends on in order for it to know that it exists before writing the header for that class.
You''re right, this should be in all FAQs on programming, especially since the more object-oriented you get the more likely it is to happen.
Eric
#ifndef RULES
#define RULES
... your code ...
#endif
, and you''d not be relying to heavily on one particular compiler.
but that''s not the problem I think you''ve got...
If you include both header files in one of the header files,
// Rules.h
#include "Rules"
#include "Data"
and include that one in both of the source files,
// Rules.cpp
#include "Rules"
...
// Data.cpp
#include "Rules"
I think that''ll keep you from a circular reference, but it''s darn bad style. You might also have to define the class that the other depends on in order for it to know that it exists before writing the header for that class.
You''re right, this should be in all FAQs on programming, especially since the more object-oriented you get the more likely it is to happen.
Eric
use the include guards as mentioned:
Also remember that any variables that are to be used in your source file must use extern like this in your header file:
extern int blah;
Then in your actual source file that uses that variable you must declare it normally like this:
int blah;
A CRPG in development...
Need help? Well, go FAQ yourself.
#ifndef _HEADERFILENAME_#define _HEADERFILENAME_#endif Also remember that any variables that are to be used in your source file must use extern like this in your header file:
extern int blah;
Then in your actual source file that uses that variable you must declare it normally like this:
int blah;
A CRPG in development...
Need help? Well, go FAQ yourself.
"There is a structure in the data class that wants to include a structure in the rules class."
So move one of these structures to a separate file. Instead of having data and rules dependent on each other, they both become dependent on the new file containing that structure.
Alternatively, refer to other classes via pointers and references. You only need to ''forward declare'' a class in the header if you just store a pointer or reference. (You will still need to include the relevant header in the source file for access to any member variables or functions.)
So move one of these structures to a separate file. Instead of having data and rules dependent on each other, they both become dependent on the new file containing that structure.
Alternatively, refer to other classes via pointers and references. You only need to ''forward declare'' a class in the header if you just store a pointer or reference. (You will still need to include the relevant header in the source file for access to any member variables or functions.)
Include guards are not bad style. They''re a very practical way to work around an intrinsic flaw/feature of both C and C++. And they are used in just about every piece of production code, so they''re obviously very widely accepted.
Guards are a good idea. But, you should also reduce the dependencies in the header files by use of the ''class'' statement.
For example, say you have class A that refers to class B in its header. However, it does not actually use anything from class B in the header; it merely refers to class B as method parameter arguments, member pointers, etc. I.e. it doesn''t actually delve into the internals of class B (it would probably do so in the .cpp file). Put a ''class B;'' in the file instead of including b.h. That way, you reduce the dependencies between files and also avoid the potential circular reference problem mentioned in this thread.
By reducing the dependencies at the h file level, you find that rebuilding the program is faster, because not as many files need to be recompiled.
For example, say you have class A that refers to class B in its header. However, it does not actually use anything from class B in the header; it merely refers to class B as method parameter arguments, member pointers, etc. I.e. it doesn''t actually delve into the internals of class B (it would probably do so in the .cpp file). Put a ''class B;'' in the file instead of including b.h. That way, you reduce the dependencies between files and also avoid the potential circular reference problem mentioned in this thread.
By reducing the dependencies at the h file level, you find that rebuilding the program is faster, because not as many files need to be recompiled.
Author
OK, I had the guards in place.
I am going to try and redesign what I want to do, and if that still doesn''t work then I guess that the best solution would be to put both classes in a common file. The reason I have the rules and data classes seperate is to reduce the size of the objects and to make it easier to change the rules without the need to know the Data, and so I don''t want to make them both dependant on a 3rd object as it will increase the size and complexity of both objects won''t it ?
I shall see how I get on, and thanks for the help !
Bp.
I am going to try and redesign what I want to do, and if that still doesn''t work then I guess that the best solution would be to put both classes in a common file. The reason I have the rules and data classes seperate is to reduce the size of the objects and to make it easier to change the rules without the need to know the Data, and so I don''t want to make them both dependant on a 3rd object as it will increase the size and complexity of both objects won''t it ?
I shall see how I get on, and thanks for the help !
Bp.
Ok, I didn''t read all the answers but I had a similar error and it was simply a misspelling in the #ifndef and #define part. Also remember that any macro can be defined somewhere else in another source file. (Long macro names rulez)
(GK)
Message from above:
Damn, my hair is grey!
(GK)
Message from above:
Damn, my hair is grey!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
