Deciding which standard header files to #include

Suppose i am editing some large C++ source file, and i add a few lines of code that happen to use auto_ptr, like in the following example.

#include <string>

// ... (much code here)

void do_stuff()
{
    std::string str("hello world");
    // ... (much code here too)
    std::auto_ptr<int> dummy; // MY NEW CODE
    // ...
}

This example compiles on gcc 3.4.4 (cygwin), because the standard header <string> happens to include the header <memory> needed for compilation of auto_ptr. However, this doesn't work on gcc 4.5.0 (mingw); they seem to have cleaned up their header files or something.

So, when i add code that uses auto_ptr, should i immediately go look whether the file contains #include <memory> at the beginning, as this answer implies? I never do it (i find it too annoying); i always rely on the compiler to check whether any #include is missing.

Is there any option that would not be disruptive to coding, and would ensure portability of my code?

Is there a C++ standard library implementation whose headers don't include e开发者_开发知识库ach other more than is required?

If you use something in the standard library, you should include the header in which it is defined. That is the only portable option. That way you avoid the instance you cite where one header happens to include another in one version or compiler, but not another. auto_ptr is defined in <memory>, so if you use it, include that header.

[edit...]

In answer to your comment... Are you asking if the compiler can help detect when you use something from a standard header you didn't directly include? This would be helpful, but I think it's a little too much to ask. This would require the compiler to know which standard library headers contain which standard library definitions, and then check that you included the right ones for the definitions you used.

Determining exactly how a header was included is also a tall task. If you are using a standard library definition, then you must be including the header somehow. The compiler would have to tell whether you included the header yourself (possibly through headers of your own or a third-party library) or whether it came through another standard library header. (For instance, in your example, it would have to be able to tell the difference between <memory> being included via <string> or being included within your own code.)

It would have to handle different version of the standard library (e.g. C++03 vs C++0x) and different vendors. And what if those vendors of a third-party stdlib do not exactly follow the standard, then you could get bad warnings about which headers to include.

I'm only saying this to try to explain (with my limited compiler/stdlib knowledge) why I don't think compilers have this feature. I do agree, it would be helpful, but I think the cost outweighs the benefit.

The best way is to include the correct header in which the construct is defined. and Include files should protect against multiple inclusion through the use of macros that "guard" the files

Generally header files have "include guards" surrounding them. The guards are formed by:

MyHeader.h:

#ifndef __MY_HEADER_H__
#    define __MY_HEADER_H__

     //body of MyHeader.h

#endif

So, you could include MyHeader.h as many times as you want:

#include "MyHeader.h"
#include "MyHeader.h"
#include "MyHeader.h"
#include "MyHeader.h"

And it won't cause any problems for the compiler (it will only ever be included once). Moreover you could include another file that includes "MyHeader.h", and the same rule would apply.

What this means is, if you ever want to use something that is defined in a header - include it! (Even if you think something else might include it, there is no reason not to be safe).