Question

So, I have the following in a specification file

#include <string>
#include <fstream>
using namespace std:

class MyStuff
{
    private:

    string name;
    fstream file;
    // other stuff

    public:
    void setName(string);
}

I also have in the implementation file

#include "MyStuff.h"
using namespace std;

void MyStuff::setName(string name);
{
     name = name
}

and in the program file I have…

#include <iostream>
#include <string>
using namespace std;

void main()
{
     string name;
     MyStuff Stuff;

     cout << "Enter Your Name: ";
     getline(cin, name);

     Stuff.setName(name);
}

And I’m gathering that applying “using namespace std;” in a header file is a no-no, and that to fully qualify is the “better” practice; such as std::cout << stuff << endl;

It is my understanding that in order to use a string, it must have the std namespace. Is that true?

If so, in the header file, is more “pure/clean” to do it as…

#include <string>

class MyStuff
{
     std::string name;
}

And, as I understand it currently, using namespace std; across all three files, specification, implementation, and program, essentially layers the three namespaces on top of each other, so if I separately declare string name; within each of the files, the compiler will not know which goes to what. Is that true?

I generally understand that being clear is a “good” thing to do, I am however a little unclear on the specificity of how, and I’m most interested in the deeper “why” that underlies it all.

So my direct question is, in my example provided, what is the “clearest” way to describe the function both for the compiler and for industry “standard”? And, can you direct me to resources that more clearly delineate the reasoning and practical implementation of namespaces.

Answer 1

Let’s say I declare a class string myself. Because I’m a lazy bum, I do so in global namespace.

// Solar's stuff
class string
{
    public:
        string();
        // ...
};

Some time later on, I realize that re-using some of your code would benefit my project. Thanks to you making it Open Source, I can do so:

#include <solarstuff.hpp>
#include <phoenixstuff.hpp>

string foo;

But suddenly the compiler doesn’t like me anymore. Because there is a ::string (my class) and another ::string (the standard one, included by your header and brought into global namespace with using namespace std;), there’s all kinds of pain to be had.

Worse, this problem gets promoted through every file that includes my header (which includes your header, which… you get the idea.)

Yes I know, in this example I am also to blame for not protecting my own classes in my own namespace, but that’s the one I came up with ad-hoc.

Namespaces are there to avoid clashes of identifiers. Your header not only introduces MyStuff into the global namespace, but also every identifier from string and fstream. Chances are most of them are never actually needed by either of us, so why dragging them into global, polluting the environment?

Addition: From the view of a maintenance coder / debugger, foo::MyStuff is ten times more convenient than MyStuff, namespace’d somewhere else (probably not even the same source file), because you get the namespace information right there at the point in the code where you need it.