- Forum
- General C++ Programming
- Headers techniques
Headers techniques
I always have headers philosophical questions ;)
when you write a.h and a.cpp you sometimes need things for the definition of the class that are not needed in the declaration. must I include the headers of those things in a.h or in a.cpp?
For instance:
a.h:
----
#include b.h
class A {
public:
void f();
};
a.cpp
-----
void A::f(){
string a = "hello World!";
std::cout << a;
}
do I need to put #include <string> in a.h or in a.cpp ?? I would say a.cpp since a.h doesn't directly need string and string is all about implementation, not interface.
WHat do you think about this?
when you write a.h and a.cpp you sometimes need things for the definition of the class that are not needed in the declaration. must I include the headers of those things in a.h or in a.cpp?
For instance:
a.h:
----
#include b.h
class A {
public:
void f();
};
a.cpp
-----
void A::f(){
string a = "hello World!";
std::cout << a;
}
do I need to put #include <string> in a.h or in a.cpp ?? I would say a.cpp since a.h doesn't directly need string and string is all about implementation, not interface.
WHat do you think about this?
You could use some #directive's to test for a definition to see if the string had already been included.
#ifndef special_string_delcare
#include <string>
#endif
If you stick that in your header, you shound't have to worry about it.
I don't know what special declaration you could use that string.h defines, but this should give you the idea.
#ifndef special_string_delcare
#include <string>
#endif
If you stick that in your header, you shound't have to worry about it.
I don't know what special declaration you could use that string.h defines, but this should give you the idea.
Last edited on
Well, first thx for answering!
My question was not especially turned on a <string> but on any object that need to be know by the compiler. What if I need to include things that are needed to be know by the cpp file but not by the .h file? Is it good practice to only put it in the cpp file?
My question was not especially turned on a <string> but on any object that need to be know by the compiler. What if I need to include things that are needed to be know by the cpp file but not by the .h file? Is it good practice to only put it in the cpp file?
If you are going to put an #include inside of a header file, you should use include guards for all of your custom headers to prevent multiple definitions.
http://en.wikipedia.org/wiki/Include_guard
I generally put the system includes in the .cpp files, I believe it is considered bad practice to use include directives inside of a header file.
http://en.wikipedia.org/wiki/Include_guard
I generally put the system includes in the .cpp files, I believe it is considered bad practice to use include directives inside of a header file.
If you have a header file, put include guards in it. Do not wrap other includes with "external" guards, that is a poor practice. (The are compiler extensions for precompiled headers or #pragmas to help with compilation time but I'm going to get into those here.)
To answer your question, you are correct that #include string should be in the source file (not the header).
When a type's definition is not necessary but there's still mention of it in a header (such as a pointer or reference declaration), you can forward declare the type in the header and include the type's header in the source file. This also helps compilation time. The pimpl idiom takes advantage of this. I encourage you to take a look at it. There is also an iosfwd header in the standard library that just forward declares some types so that you may avoid including iostream, etc..
To answer your question, you are correct that #include string should be in the source file (not the header).
When a type's definition is not necessary but there's still mention of it in a header (such as a pointer or reference declaration), you can forward declare the type in the header and include the type's header in the source file. This also helps compilation time. The pimpl idiom takes advantage of this. I encourage you to take a look at it. There is also an iosfwd header in the standard library that just forward declares some types so that you may avoid including iostream, etc..
moorecm: thx for your closer answer ;)
Sometimes I guess that you really need to include files in headers since you can't all forward declare ;)
My rules of thumb could be: forward declare when you can , include only when you do not have the choice and only at the place you need it, not elsewhere even if this elsewhere need to be included where you are ;) clear enough?
What do you think of this?
Sometimes I guess that you really need to include files in headers since you can't all forward declare ;)
My rules of thumb could be: forward declare when you can , include only when you do not have the choice and only at the place you need it, not elsewhere even if this elsewhere need to be included where you are ;) clear enough?
What do you think of this?
I have been corrected on this. I now agree with the proper practice. Thinking about puting includes into a header, I see how it would conflict when writing source code.
A programmer might want to include their own written header for the same delcartions, and then would end up with a conflict which can only be resolved by changing the header.
A programmer might want to include their own written header for the same delcartions, and then would end up with a conflict which can only be resolved by changing the header.
coerced - that's what namespaces are for. Though of course you should only include what you actually need at any given point - in your example for instance, you need neither <iostream> nor <string> in a.h, you only actually need them in a.cpp, so that's where you should include them.
About headers and includes
http://www.cplusplus.com/forum/general/13162/#msg63354
If there are parts of your class that you really want to keep invisible to readers of your header file then there is really only some simple ways around it. The C++ design does not provide a direct way to obscure any part of a class's private parts to human readers -- this would put a huge onus on the compiler to know something it has no access to: storage requirements and inline optimizations.
It really shouldn't be any big deal to let the entire definition stand in the header file.
Hope this helps.
http://www.cplusplus.com/forum/general/13162/#msg63354
If there are parts of your class that you really want to keep invisible to readers of your header file then there is really only some simple ways around it. The C++ design does not provide a direct way to obscure any part of a class's private parts to human readers -- this would put a huge onus on the compiler to know something it has no access to: storage requirements and inline optimizations.
It really shouldn't be any big deal to let the entire definition stand in the header file.
Hope this helps.
Topic archived. No new replies allowed.