I am starting out with C++ and almost everywhere I see there is these 2 sentences at the top.

#include <iostream>
using namespace std;

As I understand namespaces are something to keep names separate and have same identifiers in different namespaces. So isn't including std in the beginning undoing all the hard work of creating namespaces? Isn't it better to have something like std::cout when I need a certain function from a particular namespace?

Would including the namespace in the particular function that uses it a good tradeoff between less typing (std::cout vs. cout everywhere) and avoiding the name conflicts(abc in foo and abc in bar avoided using foo::abc and bar::abc)? Something like

Please review the suggested duplicate question as it most likely answers your question. However, if it does not answer your question, please edit and indicate what is new within your question that wasn't answered.
–
GlenH7Aug 11 '13 at 20:40

3 Answers
3

Do not put this in a header file, if this header file needs to be included by multiple source files (*.cpp).

Reason: it is contagious.

Other than that, I suggest taking a pragmatic approach to it:

Allow importing namespaces as long as it does not cause a compiler warning / ambiguity / conflict.

This brings up the question of: what is the true benefit of having namespaces? The simple answer is disambiguation. But disambiguation for who's benefit?

Disambiguation for programmers?

This is a relatively minor benefit, because most programmers are already accustomed to object-oriented programming, and the naming of objects is already sufficient for telling about the category and the purpose of that object.

However, only human can make sense from the name of objects - computers can't. (See the next point about automated tools.)

The human mind is excellent at resolving ambiguity by taking context and domain knowledge into account.

It's usually recommended not to have using namespace std. Books do it (usually with explanation) just for brevity. Similarly for other namespaces, but there are cases where you might reasonably disagree, and use it anyway.

A very good principle that comes up a lot is that if you're going to make the next person have to learn something, then make sure that they get to amortize that knowledge over a lot of uses.

That means that using namespace std should be part of a coding standard. Either you learn that anything from std is available, and you benefit everywhere. Or you don't learn that but have to type std everywhere. Either position is defensible.

The same principle goes for your internal code. It is OK to have using namespace Foo in your project, but there should be a limited number of namespaces that you import that way. And that list should be imported everywhere. Exactly so that everyone on the project is forced to learn what's in Foo and can then benefit repeatedly. But be very cautious about increasing that list - the people who are inclined to do so are the people who know your code best and who therefore have the least awareness of what it is like for people just learning your code. If you're on the fence, always err on the side of being explicit.

This generalizes much farther. Whenever you're setting up a project, thing long and hard about what people who work with the project need to know. Write down that list. Think hard about adding to it. But anything that is added to that list, should get used heavily so that you get maximum value out of the forced learning.