[Yatta!]

I'm curious if there's a "proper" way to do includes when you're using header files. To explain what I mean I'll use an example:

Assume this is a header file named "head"... (I'm so original)

#ifndef GUARD_head
#define GUARD_head

#include <iostream>

// Random junk here

#endif

Now, seeing as I have <iostream> included in the header file, and assuming that I'm including "head.h" in main.cpp, is it "proper" (emphasis on proper, I already know I don't have to) to include <iostream> again in main.cpp?

This post has been edited by Yatta!: 15 September 2011 - 12:37 AM

[PlasticineGuy]

If you need it, yes. It's always better to explicity include headers you need, even if a sub-header might include them anyway.

Also never include unnecessary headers inside other headers. iostream is a large library, and if you don't need it in the header you can cut down your code's size massively.

[Salem_c]

> I already know I don't have to) to include <iostream> again in main.cpp?
I think you should.

Consider this counter example.
100 files all include head.h, but don't separately include iostream. Sometime later, you change head.h so that it is no longer dependent on iostream, so you remove it - result - massive build breakage. Rather than fix it properly (there's a deadline), you leave iostream stuck in list.h.

In a v.large project with 10,000+ source files, you can soon imagine how creeping useless dependencies can infest whole groups of files.

Each source and header should include everything it needs, and not be dependent on other files. So if either main.cpp or list.h stop using iostream, it shouldn't break the build.

> I'm curious if there's a "proper" way to do includes when you're using header files.
There are very few blanket rules. A counter-counter example would be to have a common.h which includes iostream and a few other regulars which most things seem to need. So long as you document it as such, and make sure everyone sticks to including common.h first, it's probably a good use.

Apart from that, just don't put using namespace std; inside any .h file.

[Yatta!]

That's what I figured, thanks guys!

Quote

Apart from that, just don't put using namespace std; inside any .h file.

I assume it's because using namespace std; takes a lot of memory? Good thing I already didn't do it, then! My book just told me to type std:: manually in all of my headers

[Salem_c]

Imagine a prog.cpp like this, with multiple namespaces.

#include <iostream>
#include <foo_conflicting_with_std.h>
#include <list.h>
...
std::cout << "hello";// uses the cout in iostream
foo::cout << "Yup";  // uses the cout in foo_conflicting_with_std.h

If list.h blindly uses using namespace, then there is nothing(?) prog.cpp can do about it (it certainly won't be pretty).

using namespace std; should just be a 1-line fix for old code

#include <iostream.h>

being updated to new code

#include <iostream>
using namespace std;

without the hassle of going through the rest of the code changing cout to std::cout

But new code in a world of different namespaces needs to keep things as tight as possible.

[sepp2k]

Yatta!, on 15 September 2011 - 10:35 AM, said:

I assume it's because using namespace std; takes a lot of memory?

No, it doesn't take up any memory. The reason you shouldn't do it is that it pollutes the global namespace - not just of the header, but of any file including the header. And the more names there are in the global namespace, the more likely you are to get name conflicts.

[Yatta!]

I see. Yeah, that makes total sense. Granted I don't know any other namespace, but that's no excuse to start a bad habit!

Thanks again, guys!