Archived

This topic is now archived and is closed to further replies.

using namespace std vs std::

This topic is 6075 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

When should I choose to use one method over the other. For some reason a year or so ago when learning I decided not to use ''using namespace'' and to explicitly use (for example) std::string everywhere I wanted a string. I know it''s more typing but I got used to it and until recently when i had a discussion with Brad Pickering(Battlezone II) I didn''t even realise I coded that way. So, question is, besides raw typing and below points what are the adv\dis of using either. I think I started using it as the explicit code was more portable, as in I could easily post to a forum and everyone knew what I meant when I said std::vector , where vector may indicate a orientation not an array(for example). Just thought I''d ask before updating a few hundred files...

Share this post


Link to post
Share on other sites
Performance wise, I don''t know of any differences between explicitly using a namespace name or by using the "using" directive (since all of that should be resolved at compile time).

As for whether you should use it or not, that''s mostly a programming style issue. Personally, I don''t like to use the "using" directive since it basically defeats the whole purpose of namespaces anyway.

Share this post


Link to post
Share on other sites
Its generally easier to just use "using namespace std;" and forget about it -- particularlly if you are used to programming C++ before the STL. In anycase I believe that it all compiles to the same thing. If you want to make it more explict what is going on, you can use "std::" to tag all of the standard library stuff, but typically the only reason why you HAVE to do this is if you define your own functions / variables / classes with the same name as standard ones and you need to resolve the conflict.

Share this post


Link to post
Share on other sites
The problem with "using namespace std" is that it dumps all of the names into the global namespace. You can use the using declaration with other things besides namespaces.


#include <iostream>

// dump two names from std:: into the global namespace
using std::cout;
using std::endl;

int main()
{
cout << "hello, world!" << endl;

char c;
cin >> c; // error: no ::cin
std::cin >> c; // ok
}



You could also place those using declarations into the main function if you wanted to; of course they would have local scope instead of global scope.

Explicitly qualifying the scope isn''t very portable; what if you want to use someone else''s STL from a different namespace?


class someclass
{
public:
typedef std::string string;

someclass(const string& s);
};



This way you get the notational convenience of dropping the std:: namespace and localize any changes in the string type to one place in the code. The one caveat is that you must explicitly qualify the scope if you use it as a return value from a member function:


const someclass::string someclass::function(const string& s)
{
return s;
}



Note the implicit qualification on the second string. Since someclass::function is a member function of someclass, the string argument is assumed to be someclass::string.

Share this post


Link to post
Share on other sites
IMHO, there''s nothing wrong with putting "using namespace std" at the top of a .c file. That''s the module being compiled, and so it won''t clobber any other modules unless you''re using another module that is not protected by a namespace and has colliding class names.

However, there is everything wrong with putting "using namespace std" in an .h file. If you do this, every object (including all client objects) that include this .h file MUST accept the std namespace as global.

So, in my stuff, I like "std::" only in the header file and a single "using namespace std::" in .c files.

Share this post


Link to post
Share on other sites