There seem to be different views on using \'using\' with respect to the std namespace.
Some say use \' using namespace std
\', other say don\'t but rathe
Beside to the many correct answers here, I want to state an often forgotten detail: The concept of translation units in C++ seems to be misunderstood by many developers due to common coding and linking schemes. It's common for most of us, that .h files are header files and .cpp files yield the implementation details but that's rather a consent than a strict rule of the standard. How you finally compound your translation units is up to you in doubt.
So for instance with UnityBuilds (linking everything to one single translation unit for speed-up and memory purposes), you can no longer rely on the common consent, that using namespace in .cpp files is quite ok in general. Some might argue, that UnityBuilds circumvent several major C++ core philosophies and are therefore a topic on their own, but nevertheless there are further scenarios where similar issues can occur (local includes in functions for instance). Similar issues arise here with the usage of anonymous namespaces by the way.
Since this was an issue to me in the past, I came up with the "inner guideline" to make things as explicit as possible as long as proportionality allows it.
You should never be using namespace std
at namespace scope in a header. Also, I suppose most programmers will wonder when they see vector
or string
without std::
, so I think not using namespace std
is better. Therefor I argue for never be using namespace std
at all.
If you feel like you must, add local using declarations like using std::vector
. But ask yourself: What's this worth? A line of code is written once (maybe twice), but it's read ten, hundred or thousand times. The saved typing effort be adding a using declaration or directive is marginal compared to the effort of reading the code.
With that in mind, in a project ten years ago we decided to explicitly qualify all identifiers with their full namespace names. What seemed awkward at first became routine within two weeks. Now, in all projects of that whole company nobody is using using directives or declarations anymore. (With one exception, see below.) Looking at the code (several MLoC) after ten years, I feel like we made the right decision.
I've found that usually, those who oppose banning using
usually haven't tried it for one project. Those who have tried, often find it better than using directives/declarations after a very short time.
Note: The only exception is using std::swap
which is necessary (especially in generic code) to pick up overloads of swap()
that cannot be put into the std
namespace (because we aren't allowed to put put overloads of std
functions into this namespace).
This discussion is going to be alive as long as the IDE you work with is not flexible enough to show or hide the exact information you need.
That is because what you want your code to look like depends on the task at hand.
While creating my source code, I prefer to see exactly which class I'm using: is it std::string
, or the BuzFlox::Obs::string
class?
When designing the control flow, I'm not even interested in the types of the variables, but I want a focus on if
's and while
's and continue
's.
So this is my advise:
Depending on the audience of your code and the power of your tools, choose the way that either reads easiest, or gives most information.
There are several ways to fix that.
First: use like what you did.
Second: do namespace S = std;
, reducing 2 chars.
Third: use static
.
Fourth: don't use names that std
uses.
Both
using std::string;
and
using namespace std;
add some symbols (one or lots of) to the global namespace. And adding symbols to global namespace is something you should never do in header files. You have no control who will include your header, there are lots of headers that include other headers (and headers that include headers that include headers and so on...).
In implementation (.cpp) files it's up to you (only remember to do it after all #include directives). You can break only code in this specific file, so it's easier to manage and find out the reason of name conflict. If you prefer to use std:: (or any other prefix, there can be many namespaces in your project) before indentifiers, it's OK. If you like to add identifiers you use to global namespace, it's OK. If you want to bring whole namespace on your head :-), it's up to you. While the effects are limited to single compilation unit, it's acceptable.
Excluding the basics (Having to add std:: infront of all stl objects/functions and less chance of conflict if you don't have 'using namespace std')
It is also worth noting that you should never put
using namespace std
In a header file, as it can propagate to all files that include that header file, even if they don't want to use that namespace.
In some cases it is very beneficial to use things like
using std::swap
As if there is a specialized version of swap, the compiler will use that, otherwise it will fall back on std::swap
.
If you call std::swap
, you always use the basic version, which will not call the optimized version (if it exists).