Thoughts about using namespace std?

Someone who is pro-"using namespace std" said this:

Quote:

---

Code is much more readable if the namespace is not specified with each call but simply specified at the beginning of the file. As you mentioned, there is a benefit to specifying the namespace with each use. However, the cost is higher than the benefit.

---

Does anyone have any thoughts as to how I might convince them that

Code:

---

std::cout << x;

---

is better than

Code:

---

using namespace std;
cout << x;

---

?

I guess I shouldn't say that they are pro-"using namespace std". They're just in favour of making code as readable as possible.

I cannot give you a general answer to this question. I typically just keep typing std::whatever until I am sufficiently fed up with doing it and opt to utilize the using keyword. However, I do not like to rid my code of namespaces too much since they often give a little more clarity as to what you are doing. I think the answer is not only implementation specific but a matter of opinion as well. I often continue to type std:: in instances where others may not. Just don't put any using keywords in a header, and you will keep most folks happy.

Convince them that 6 is better than 1/2 a dozen? Probably not.

But, you can make your points for why you prefer one over the other. I don't think "cost" has anything to do with it at all. The amount of time it takes to type "std::cout" versus "cout" is not measurable in the scheme of things.

Particularly since if you constantly type std::cout you are typing it without even thinking too hard about it. I say trading off between the two is more of a cost issue than anything. I prefer environments where I have the freedom to decide my style on my own. Though how often do things work like that...

In C++ Coding Standards, Sutter and Alexandrescu actually recommend using using directives in source files, after all the includes, on the basis that it improves readability and is precisely a main reason for namespaces (as opposed to name prefixes, presumably). Koenig and Moo do not even mention using directives in Accelerated C++ (or they only give it a brief mention, I have forgotten the exact details), and instead show the use of using declarations.

I agree with master5001: the rule that everyone agrees on is that one should avoid using directives and using declarations in header files (except within some restricted scope, if it is necessary). Personally, I tend to only use them at function scope to reduce "code clutter" when I feel that it improves readability, or at class scope when necessary.

Oh, and on Meyers' recommendation, I often have a using declaration for std::swap when implementing swap functions, the idea being that if there is a non-member swap available, it will be used, otherwise the generic swap will be used.

Hmm, well, thanks for the comments.

I know it's just a matter of opinion, sort of like indentation styles. I was just hoping that someone might be able to come up with another argument besides mine, which is "that's what namespaces are for, to avoid naming collisions". :)

Well like indentations there may not be an easily defined "right way" but there are categorically wrong ways. I mean... if your code starts to become very difficult to follow because your usage of namespaces (not just the standard namespace) is just plain cluttering, there is a problem.

Example:

Code:

---

my_buddy_ricks_lib::os_independant::types::my_float x = 0.0f, y = my_buddy_ricks_lib::os_independant::constants::pi;
mylib::os_independant::graphics::renderer::drawing2d::draw_box(x, y);

---

Right? I mean it is simply two variables declared then used in a single function call, however at first glance it looks like someone accidentally paste a linker warning into their source code or something.

Quote:

---

Originally Posted by master5001

Right? I mean it is simply two variables declared then used in a single function call, however at first glance it looks like someone accidentally paste a linker warning into their source code or something.

---

That was funny :D

That said, a namespace alias might be a reasonable alternative to using directives and using declarations in the example.

As for myself I hate symbols that require shift. But I hate symbols in general. For me I prefer the Haskell style add x y rather than add(x,y) and the tabs instead of the brackets. So I would go for the using keyword. But that is a bad reason I suppose :P

Quote:

---

As for myself I hate symbols that require shift.

---

You lucky bastard :) When I need the xor symbol, I type Alt + 94 (on a laptop without a numeric keyboard)... (Actually, it seems I can type two of them with another key combo.)

Anyway, using directive in source files doesn't mean that you cannot solve naming conflicts. So if you don't need the constant remainder that cout comes from std it should be quite OK.

In headers, I understand, it may put the namespace in effect in any other headers that are included after this.

Personally, if I kept using using I would forget what namespace cout comes from within a program or two. That is just me...

how about a compromise?

Code:

---

using std::cout;
using std::endl;

//for everything that's often used

---

That way the global namespace is not polluted too much, and you don't have to type "std::" over and over again.

There are two main reasons that I prefer always typing std::.

First, I prefer the consistency. Since I use standard names in header files and follow the rule to not use using directives or declarations in header files, I like to be able to switch to the source file and see the type look the same there as it does in the header. It takes extra mental effort to know that map is the same as std::map.

Second, I like making it obvious where the type comes from. Any type that includes the std:: prefix is from the standard library. If it has boost:: then it is from boost. If it is from some other namespace, then that is obvious as well. This is especially true when your variable names use lowerCamel or the lower_with_underscore style that the standard library uses, and your class types follow a different convention. Using standard library names without the namespace makes it harder to discern that they are types.

Can you use both styles? Like using the using namespace std but still using types like std::map. For example, maybe you want to do that only to be able to write cout instead of std::cout, but all the rest you want the std:: . Will it be completely wrong? Is it bad practice?

I also use a laptop and the left shift... they made it small. And yes, dear manufacturer there is a reason shift is a big button in the first place (damn Plaisio)

Quote:

---

It takes extra mental effort to know that map is the same as std::map.

---

But I think that regardless of whether you have using namespace std; or not you can still type std::map if that is one of the few things that cause you mental effort :)

Anyway, I tend to typedef containers, so the code would really seldom contain std::.

>> But I think that regardless of whether you have using namespace std; or not you can still type std::map
True, but then there would be no point to the using directive.

>> Can you use both styles?
Use a using declaration (e.g. using std::cout) if you want to only bring in some of the names. Consistency is important when determining a coding style, so it rarely makes sense to do both in the same place.

Quote:

---

Originally Posted by anon

You lucky bastard :) When I need the xor symbol, I type Alt + 94 (on a laptop without a numeric keyboard)... (Actually, it seems I can type two of them with another key combo.)

---

No worries... just type xor:

Code:

---

#include <iostream>

int main()
{
    std::cout << "Look " << (1 xor 1) << " wow!!\n";

    return 0;
}

---

You can do the same thing in C99 by including iso646.h.

Quote:

---

Originally Posted by C_ntua

Can you use both styles? Like using the using namespace std but still using types like std::map. For example, maybe you want to do that only to be able to write cout instead of std::cout, but all the rest you want the std:: . Will it be completely wrong? Is it bad practice?

---

Oh yes, it's possible. The compiler won't care if you use the full prefix std:: even if you use using namespace std.

I like to explicitly specify namespaces because of one fact: to me, they are a way to organize stuff. Therefore I can put a function named Allocate (which is pretty unambiguous, no?) into a namespace Memory (now it's not unambiguous), and explicitly type Memory::Allocate(). It adds clarity to what function it is and allows you to group them together.
Who is to say, then, that you should not do the same for std? Prefixing std:: will let you know it's a standard function.

And if the namespace is too long -> I::Am::A::Very::Long::And::Totally::Unnecessary::N amespace, just use a using declaration -> using I::Am::A::Very::Long::And::Totally::Unnecessary::N amespace = MyNSpace (or is it the other way around?).

It's my best argument for explicitly using namespaces! Does that help?

Quote:

---

And if the namespace is too long [...], just use a using declaration

---

I prefer namespace aliases, which is what I think you want here:

Code:

---

namespace fs = boost::filesystem;

---

Oh yes, that's what they're called.
Namespace aliases.

Quote:

---

Originally Posted by dwks

Someone who is pro-"using namespace std" said this:

Does anyone have any thoughts as to how I might convince them that

Code:

---

std::cout << x;

---

is better than

Code:

---

using namespace std;
cout << x;

---

?

I guess I shouldn't say that they are pro-"using namespace std". They're just in favour of making code as readable as possible.

---

Unlikely, though you can advocate a safer use of the directive by restricting its scope:

Code:

---

#include <iostream>

int main()
{
  using namespace std;

  //...

  cout<< x;
}

---

If your friend complains that he has to type it too often, you can use that to suggest more regular use of namespaces for program organization:

Code:

---

#include <iostream>

namespace mystuff {
  using namespace std;

  void foo()
  {
    //...
  }

  void bar()
  {
    //...
  }
}

int main()
{
  //...
}

---

I got used to typing std:: at first, but when I started to use algorithms more often, I found that it has the tendency to add large amounts of noise.

Code:

---

std::vector<std::string>::const_iterator it = std::find_if(strings.begin(), strings.end(), std::bind2nd(std::greater<std::string>(), "eek"));

---

Ok, the container might be typedeffed, and the whole thing could be spaced out over multiple lines, but this still leaves 20 characters (and 15 what might be on a single line) that contain practically no useful information. (And with using directive, this particular line might fit into the window on a single line.)

I came into the habit of std::ing everything cause I read someone with more posts than I say it was good; which is a really bad way of coming into a habit, now that I think of it. In light of this topic does anyone find this amusing?

Code:

---

C Board > General Programming Boards  > C++ Programming  >  Thoughts about using namespace std?

---

>> Ok, the container might be typedeffed
I wish I did that in a project of mine... I had a global std::map<std::string,std::map<std::string,std::vec tor<std::string> > > over 6k lines of code and didn't think to typedef it (still haven't), and I had to change it. I find that you just get used to typing std::. Nearly feels wrong writing string in code without it to me.

i got into the habit of std:: everything. i think a good compromise is to have:

Code:

---

using std::cout;

---

that way you don't have to type std:: all the time and helps avoid naming collisions.

Quote:

---

Originally Posted by bling

i got into the habit of std:: everything. i think a good compromise is to have:

Code:

---

using std::cout;

---

that way you don't have to type std:: all the time and helps avoid naming collisions.

---

Agreed. I prefer to use using in a less encompassing manner just as you have in your example.

Of course, the result of that sometimes is that you type a lot just to use cout or anything else once in the source file :)

And the thing is, if the chosen name (e.g cout) just happens to collide with anything, you'll still get a surprising error.

As I see it namespaces give you an opportunity to choose whether you need to disambiguate between names or not. Even with the using directive, you can still resolve naming conflicts in source files, should they arise. The namespace isn't irreversibly polluted. (But for beginners it is probably recommended to not use this freedom.)

-------
I'm no expert in Python, but compare it with the similar thing in Python: from somewhere import * (make names in "somewhere" visible without the module name):

Code:

---

>>> from math import *
>>> def abs(x):
...    print "my abs"
...    return x < 0 and -x or x
...
>>> print abs(10)
my abs
10
>>> print math.abs(-10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'math' is not defined
>>> del abs
>>> print abs(-10)
10

---

It seems that my abs shadows the abs function in math completely, and that there's no way to access the math one unless my version is removed from the interpreter.

In C++ I could always type either ::abs or math::abs.

For me, as a rule of thumb I never use using * until I find that I have typed something like 45 times. Ironically enough, usually immediately after adding the using * I only use * like twice. So you are right... I just don't necessarily do it very often. Even in my examples I rarely utilize using. I just write

Code:

---

std::cout << my_string << ' ' << my_int << std::endl << my_other_string << ' ' << my_other_int << std::endl;

---

I have not yet found the typing of five letters to be counterproductive. Plus I typically use the c standard io library more than iostreams. Though according the the standard, technically one needs to be typing out std::printf() too... But what are you gonna do.

Quote:

---

Originally Posted by dwks

Someone who is pro-"using namespace std" said this:

Does anyone have any thoughts as to how I might convince them that

Code:

---

std::cout << x;

---

is better than

Code:

---

using namespace std;
cout << x;

---

?

I guess I shouldn't say that they are pro-"using namespace std". They're just in favour of making code as readable as possible.

---

A major part of code readability is not an issue of text obscurity, but instead of code interpretation. In that sense, std:: is more readable than the lack of it because it doesn't remove from the reader the ability to immediately recognize the object namespace. Code semantics is preserved.

Readability is also a task of the reader as much as it is of the coder. As a programmer I certainly should strive to make my code readable and understandable. But as a reader I'm not suddenly free from any obligation. It's my responsibility to actually make an effort. Certainly I cannot expect C++ to read as a pocket novel. In fact as a reader I should be suspicious of oversimplification. Any code that seems to do so, should trigger my senses into sharp mode and make me read more slowly.

On the other hand, if I'm reading code with the task of maintaining it, the issue of code readability is not one of form or style anymore, but one of semantics. Code readability here will be more an issue of my ability with the programming language, than it will be about the original programmer choices to make my task easier.

Necessarily, I think the using directive as an evil thing when placed at global scope. Even more so when placed on a header file where the tool suddenly becomes a weapon. As Prelude suggested there's better uses to the using directive and even so it should only be done in context; If the local code to where the directive is applied makes heavy use of the namespace name, this heavy use interferes with normal flow of readability and there's no risk of future code to introduce nameclash issues.

One final note goes to the application. I cannot consider the using directive useful in a small scale application. If the issue is typing less I suggest the programmer to not code in C++ but choose some other language. In a small scale application, such aim can only be perceived by me as lazyness. But in any case, even if i'm overstating, the programmer better get used to write a lot, and not to write less. That's just one of the aspects he will have to deal with in C++ if he chooses this to be his language. On the other hand, on large scale applications where it's conceivable for this tool to have some form of use, that's exactly where it's use may become more damaging and where its hould be avoided except on local scope and for those situations I suggested.

In any case I would prefer if the programmer understood std:: as a normal part of his C++ lexicon.

>>A major part of code readability is not an issue of text obscurity, but instead of code interpretation. In that sense, std:: is more readable than the lack of it because it doesn't remove from the reader the ability to immediately recognize the object namespace. Code semantics is preserved.

Yes, but the object namespace is not more important than the object itself. When you right namespace::object you read two things. When you write object you read one thing. Having more information is not always good. You might not care from which namespace it belongs. Especially it that namespace is well known, like std.

What will the std:: help you? It will tell you that the object is from the standard library. But since it is standard it kind of loses its usefullness. I would like to know from which namespace an object is if you have 100 manually defined namespaces. But even still, I can assume that whatever has no :: is standard. So especially for the std namespace I don't find it bad to be included, even if it is the only one you use.

C_ntua, a primary example of Mario F.'s points is the string class. "Which string class?" you are probably asking. The answer is simply "good question." There are oh so many different ones in so many different libraries. It is a very common name for a very commonly needed type of class. Few are ever overly interchangeable. So if you are writing code that uses the STL and wxWidgets and Irrlicht, for example (i.e. you are writing a platform independant game) you have three separate libraries each with their own string class.

Quote:

---

It will tell you that the object is from the standard library. But since it is standard it kind of loses its usefullness.

---

You are forgetting a namespace is a non-trivial matter and that it has scope implications. That is, this is not only a matter of preference. It needs to be weighted with the consequences. EDIT: and master5001 just named one example.

Quote:

---

But even still, I can assume that whatever has no :: is standard.

---

You can't actually, because any name you define yourself outside of a namespace is not "standard". Consequently, when reading code the original programmer is making no distinction between his own names and those of the std.

Quote:

---

What will the std:: help you?

---

Me the reader? Little probably. Depends on my knowledge of the language and how easily I can identify standard names at a glance and how much information I can retain while reading the code. Me the coder? Depends on several factors, but for the most part I can conceded to the fact it won't have any practical benefit in the short term.

Question is if that is a reason to not write it. I tried to reason why it should be written on most circumstances. There's others I didn't find the need to repeat -- like Daved's call for consistency which is equally important.

However the strong point I try to make on that post is that we tend to look at readability as only a matter of form. It isn't. For me, the presence of std:: doesn't make the code less readable. It in fact makes it more readable. So there is also the issue as to exactly how many find std:: invasive.

Code readability on the other hand is much more about expressiveness, and while you can still make a case of std::, it will be a weaker one.

it sounds like this discussion is derailing into should a brace have its own line or not. i used to have the brace on the same line. but then i switched jobs where braces are on new lines. i hated it with a passion for about a week, but then i got used to it and now i don't mind.

i think it's the same thing with std::. those who prefer one or the other could probably very easily be switched to the other given the time for them to adapt.

I gather you didn't actually read the thread or it's a matter of readability. Either:

a) we didn't make very readable posts, or
b) you didn't make an effort to understand what is being said

I put my money on b.

readability is subjective.

edit: wasn't there a time when people actually liked hungarian notation?

Hungarian is fine, in my opinion. I know the reasons people give for not liking it... and I'm not sure if they have enough bite to really make it an issue. Any naming convention is good, as far as I'm concerned. Be it in how you name variables or how you call functions I think consistency is good. With using namespaces ... I don't do it. I always feel better knowing exactly from where something is being called, function names, objects etc can't always be unique. Sometimes it's nearly obvious. But with programs interfacing to many libraries, namespaces for many different uses... it could be messy, but I prefer clarity. Anon's example above shows how messy it can be, but with a quick glance what type is the 'twomers_or_std' variable? Without referring to the top.

Code:

---

namespace twomers {
  template<typename _Ty,typename _Ax = allocator<_Ty> >
  class vector{};
}

using namespace std;
using namespace twomers;


int main( void ) {
  vector<int> twomers_or_std; // ?

  // No confusion
  twomers::vector<int> twomers_vector;
  std::vector<int> std_vector;

  return 0;
}

---

Quote:

---

Originally Posted by twomers

but at a quick glange what type is the 'twomers_or_std' variable? Without referring to the top.

---

At a quick glance, the program would not compile even if the ambiguous statement was removed ;)

But what your example shows is that having two using directives in the same scope can make things confusing. It does not show that using directives necessarily introduce confusion, and even then confusion can always be avoided by explicitly qualifying names in conflict, or by switching to using declarations.

>> At a quick glance, the program would not compile even if the ambiguous statement was removed
It compiles fine on MSVC '03. I don't think it matters that my simple test case isn't an exact replica of the problem at hand, but it shows that using them globally can.

>> But what your example shows is that having two using directives in the same scope can make things confusing.
So take out the twomers namespace and make a class called vector and retain using namespace std.

Code:

---

template<typename _Ty,typename _Ax = allocator<_Ty> >
  class vector{};

using namespace std;

int main( void ) {
  vector<int> local_or_std; // ?

  return 0;
}

---

Same problem. Which vector is it?

Edit: I'm not saying this is a good example or anything. It's a lousy one, in my opinion. But it does highlight potential issues with the problem, especially if you're attempting to do something 'standard' with a good name and are in the habit of using namespaces. Just showing potential for confusion.

Quote:

---

Originally Posted by twomers

It compiles fine on MSVC '03. I don't think it matters that my simple test case isn't an exact replica of the problem at hand, but it shows that using them globally can.

---

I just found it surprising that you used allocator without fully qualifying it, despite claiming that "With using namespaces ... I don't do it." Of course, there is also the missing header inclusion, but that's forgivable.

Quote:

---

Originally Posted by twomers

So take out the twomers namespace and make a class called vector and retain using namespace std.

---

You still have two using directives in the same scope, except that one is implicit since it concerns the global namespace.

EDIT:

Quote:

---

Originally Posted by twomers

Edit: I'm not saying this is a good example or anything. It's a lousy one, in my opinion. But it does highlight potential issues with the problem, especially if you're attempting to do something 'standard' with a good name and are in the habit of using namespaces. Just showing potential for confusion.

---

I agree, though I think that by "using namespaces" you actually mean "using using directives or using declarations" ;)

My opinion is that if the using directive is within some restricted scope, there would generally be less of a problem since the fact that there is a using directive at work would be more obvious to the reader. On the other hand, I find that the opportunity to use using directives and using declarations is not that common, since I only use them when necessary, or to make a piece of code that uses the namespace name far too often more readable.

As long as we're at it, why don't we use ::std::cout?

Personally, I like to use using for very important common libraries, like std. Other lessly used libraries I will just type out. One advantage with using :: is on some ide's they have the code completion, which I think helps out greatly.

>> I just found it surprising that you used allocator without fully qualifying it
Heh. I was just copying what intellisence was telling me std::vector used as template arguments. I figured it would make it more 'complete' in a sense.