Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I realize there are subtly different semantics for some of these, because of ADL.

In general, though: Which one should I prefer (if any), and why?
(Or does it depend on the situation (e.g. inline header vs. implementation?)

Also: should I prefer ::std:: over std::?

using namespace std;

pair<string::const_iterator, string::const_iterator> f(const string &s)
{
    return make_pair(s.begin(), s.end());
}

or

std::pair<std::string::const_iterator, std::string::const_iterator> f(const std::string &s)
{
    return std::make_pair(s.begin(), s.end());
}

or

using std::pair;
using std::string;

pair<string::const_iterator, string::const_iterator> f(const string &s)
{
    return make_pair(s.begin(), s.end());
}

or

std::pair<std::string::const_iterator, std::string::const_iterator> f(const std::string &s)
{
    using std::make_pair;
    return make_pair(s.begin(), s.end());
}

or

std::pair<std::string::const_iterator, std::string::const_iterator> f(const std::string &s)
{
    using namespace std;
    return make_pair(s.begin(), s.end());
}

or something else?

(This is assuming I don't have C++11 and auto.)

share|improve this question
1  
See stackoverflow.com/questions/1265039/using-std-namespace for a starting point. –  AProgrammer Mar 24 '12 at 7:45
    
@AProgrammer: Ah, thanks for the link, that answers part of my question. :) Still wondering about ::std:: vs. std:: though. –  Mehrdad Mar 24 '12 at 7:49
3  
I'm using std without second though. Someone defining a std namespace is asking for trouble (and probably searching to take advantage that most people are using std and not ::std). –  AProgrammer Mar 24 '12 at 11:35

3 Answers 3

up vote 16 down vote accepted

Avoid using using in headers, because that breaks the purpose of namespaces.

It is ok to use it in source files, but I would still avoid it in some cases (for example using std).

However if you got nested namespaces, it's ok :

namespace A {
namespace B {
namespace C {
class s;
} // C
} // B
namespace D{
using C::B::s;
} // D
} // A
share|improve this answer
4  
+1 it's amazing how many tutorials and college courses just tell you to use the using keyword without a thorough explanation of why namespaces are used to begin with. –  Jeffrey Sweeney Mar 24 '12 at 13:19
    
People want to get on with using iostreams, strings, and so on. They don't want to have to type std:: every single time they want to use a thing, or have to remember yet another piece of boilerplate to put before their code, which will cause less-than-helpful errors if they forget it. :( –  Colen Mar 24 '12 at 20:34
    
Would something like typedef std::string sstring; be an alternative? –  Giorgio Jun 17 '12 at 9:16
1  
@Colen: These poor souls can use using std::cout and friends, but it's not like cout is already a horribly long name. –  Benjamin Bannier Aug 3 '12 at 11:43
1  
If you're a college student in your first day of "my first C++ class", it's yet another thing that can cause syntax errors that you don't understand. It's easy for us to figure out because we're experienced programmers, but when you're trying to learn the language, it's yet another thing to have to worry about that you don't need. –  Colen Aug 3 '12 at 18:00

When putting a using statement in a source file, PLEASE, just pull in the things you need. For instance:

using std::string;
using std::ostringstream;

The issue here is that if you do

using namespace std;

you pull in EVERY SINGLE THING from std into the global namespace. Which leads to very interesting error messages when you accidentally use a name in your code that matches one you were completely unaware of in std. If you just pull in the stuff you want, then you won't have that problem (or, more precisely, the next programmer to work on your code won't have that problem).

share|improve this answer
    
Alternatively, you can using namespace just in a function scope, avoiding the issue. –  Tamás Szelei Aug 3 '12 at 11:58
    
@fish - actually, doing 'using namespace' in function scope doesn't avoid the issue, it just limits the space where things can go wrong. And if you end up putting 'using namespace' in every function, it's not much different from just doing it globally. –  Michael Kohne Aug 3 '12 at 12:47
    
While C++ indeed does allow one to declare types on the function level, it is not a common thing; other than that, the possible name clashes are easy to spot from the compiler output (but you are right that this does not prevent them). –  Tamás Szelei Aug 3 '12 at 15:02

As VJovic indicates, do not use using in a header file. using in a header file affects the current compilation unit (the .cpp file) in ways that the source file may not be expecting.

using namespace is also to be avoided in a source file. This brings every symbol into the same scope as the source file. It is more clear to your readers what you are doing if you use specific symbols from the namespace.

share|improve this answer
2  
As a practical concern, unless your code overrides commonly-used names, I'd much rather see using namespace JoystickModule at the beginning of a .cpp file than JoystickModule:: attached to every object throughout. –  Alex P Jun 3 '12 at 16:29
    
@AlexP: That's exactly how I do it. One using statement for my own namespace I'm currently working on and everything else stays namespaced. –  Benjamin Kloster Aug 3 '12 at 11:25
    
I should elaborate on "use specific symbols from the namespace". Rather than prefixing each symbol on every use, which does not help with readability, I prefer to use explicit symbol hoisting. using SomeNameSpace::SomeSymbol. This avoids moving every symbol from the the namespace into the current scope. –  Bill Door Sep 7 '12 at 16:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.