Thread: What's "best practice" between 'using namespace std' and 'std::count/std::cin'

using namespace and even 'using ...' should probably be avoided in header files, even if encapsulated in a namespace (i.e. not in the global namespace). At first it is easy to think that something like the following is okay:

Code:

//header1.h
/* standard includes */
namespace my_awesome_project {
using namespace std; // OK?

/* lots of code */

}

//header2.h
/* standard includes */
namespace my_awesome_project {
using namespace std; // OK?

/* some more lots of code */

}

Users of the code in these headers can make use of it easily enough by either using a 'using namespace' or by using a namespace alias:

Code:

//user1.cpp
/* standard includes */
#include "header1.h"
using namespace std;
namespace awe = my_awesome_project;
using awe::Some_type;

int user1() {
  Some_type obj(123);
  cout << awe::some_function(obj) << endl;
  return 0;
}

//user2.cpp
/* standard includes */
#include "header2.h"
namespace proj = my_awesome_project;
using std::endl;

int user2() {
  std::vector<proj::Some_other_type> vt;
  vt.push_back(proj::make_something_else(123));
  vt.push_back(proj::make_something_else(124));
  vt.push_back(proj::make_something_else(125));
  std::cout << proj::some_other_function(vt) << endl;
  return 0;
}

Notice that user2 has decided to avoid 'using namespace std' and use std:: everywhere. That's fine, but suppose he changes the vector declaration to the following:

Code:

proj::vector<proj::Some_other_type> vt;

proj::vector is actually std::vector, but because you imported std into my_awesome_project (which user2 has renamed to proj), you have unintentionally given him access to std::vector through your namespace. The author of my_awesome_project almost certainly intented that only her own types and functions should be in the namespace.

Additionally, if a user does end up referring to something like proj::vector, the maintainer of my_awesome_project has now committed herself to forever include the 'using namespace' lines in her header files, as not to do so would break user2's code.

I/O can just choose to flush whatever you input to it. Some implementations can also choose to flush if they see a newline. There's not much you can do to avoid flush, but you can guarantee that it will flush by using std::endl.

Yes, and guaranteeing that it flushes, say, every iteration of a loop, or even multiple times per iteration, may degrade the performance, which is easily testable. That's true if the implementation doesn't flush on every input or on every newline in said input. Of course, even if it does flush every time - we can just choose to buffer on our own.