another #include question

If you put an #include where appropriate in a header file, should you duplicate it in the file where you have the function definitions as well as in the file with main()?

Here's an example:

I'm using strings and hence put in the file account.h the statement #include <string>

Now in the file account.cpp, the following will compile:

Code:

---

#include <iostream>
#include "account.h"
using namespace std;

void Account::showAcct() const
{
        cout << "Name: " << name << endl;
        cout << "Account number: " << acctNum << endl;
        cout << "Balance: $ " << balance << endl;
}
void Account::deposit(const double depAmt)
{
        balance += depAmt;
}
void Account::withdraw(const double wdAmt)
{
        balance -= wdAmt;
}

std::string Account::test()
{
        return "tested";
}

---

The last function I even threw in extra just to see if it would work without the #include.

I also don't have a #include <string> in the file with main(), but it also doesn't make explicit use of strings and does have #include "account.h" of course.

Is it good programming practice to put the #include in explicitly in all these spots even though, using this case as example, <string> gets included because it's included in the account.h file?

Or, asking my question a bit differently, should you explicitly #include the various libraries you need even if you've indirectly #included them already through reference in a header file?

Well, only the person who created the header fie knows what all its including. So its more clear to include them as you need.

If you use a string in the file, then #include <string>.

In this case, you are using strings in account.h and account.cpp, so #include <string> in both. You are not using strings in main, so don't #include <string> there.

Quote:

---

Originally Posted by Daved

If you use a string in the file, then #include <string>.

In this case, you are using strings in account.h and account.cpp, so #include <string> in both. You are not using strings in main, so don't #include <string> there.

---

If I #include a file in a header, I usually don't #include it in the .cpp file of that header; what's the point? I'd be #including it twice then. Plus, if I remove it later, I'd have to remember to remove it from both files.

On the other hand, if you #include a header file in the main .cpp or an unrelated .cpp, then it would probably be better not to rely on certain header files always being included, otherwise you end up with tight coupling...

A header and the .cpp that directly belongs to it are basically one unit as far as I'm concerned; so I don't duplicate #includes between them.

Quote:

---

Originally Posted by cpjust

A header and the .cpp that directly belongs to it are basically one unit as far as I'm concerned; so I don't duplicate #includes between them.

---

I tend to agree with that.

However (and I realise cpjust is not suggesting otherwise) that does not mean that headers should #include everything.

Essentially I write headers to #include everything that is necessary for code to use the functionality of a "unit", and .cpp files to #include everything (usually including the header) needed to implement the functionality of a "unit".

>> if I remove it later, I'd have to remember to remove it from both files.
Actually, that's a bad idea. The rule is to #include it where you use it. If you remove it from the header, how do you know you don't use it in the cpp file separately from how it was used in the header?

>> that does not mean that headers should #include everything.
Of course not. Each file should include what it uses. That way you don't have to worry.

Quote:

---

Originally Posted by Daved

>> if I remove it later, I'd have to remember to remove it from both files.
Actually, that's a bad idea. The rule is to #include it where you use it. If you remove it from the header, how do you know you don't use it in the cpp file separately from how it was used in the header?

---

Obviously you'd need to selectively remove it from either the header or both, but it's still one more thing to needlessly worry about. I treat it kind of like the rule of declaring variables closest to their first use... If I need a type in the header file, I #include it there, otherwise if I only need it in the .cpp file, I include it there.

>> If I need a type in the header file, I #include it there, otherwise if I only need it in the .cpp file, I include it there.
That's fine, but I don't think that's what we're talking about.

The question is whether one should include the header in the source file if it is used in both the source and the header and is already included in the header. IMO, the answer is yes, absolutely. The reason is that if you no longer need it in the header, and therefore remove it, you could inadvertently break the source file.

Obviously this isn't a big deal, but to answer the OP's question, I would rather have a simple and steadfast rule with one extra step than take the chance of inadvertantly breaking my code.

Quote:

---

Originally Posted by cpjust

Obviously you'd need to selectively remove it from either the header or both, but it's still one more thing to needlessly worry about.

---

I think that you may have to worry about getting the includes right either way. Consider a case where you require <istream> in a header. After maintenance, <iosfwd> is required, but <istream> is included via another header, say another standard header. You distribute the source, and some users complain that the program cannot compile. It turns out that on a different implementation, <istream> is not included via that other standard header, and you forgot to #include <istream> in the source file.

Quote:

---

Originally Posted by cpjust

I treat it kind of like the rule of declaring variables closest to their first use... If I need a type in the header file, I #include it there, otherwise if I only need it in the .cpp file, I include it there.

---

In a way, I agree: if I can get away with a forward declaration of a class instead of its entire definition, I try to do so.

cpjust's solution seems pretty solid to me. Thanks very much to all for the very helpful discussion!