Question about 'using namespace'.
Should I use 'using namespace'?
The reason I am asking is because I'm using multiple libraries with each having their own namespaces. It seems as things grow more complex that it is easier to read the code leaving the namespaces in - even if they are occasionally very long and common.
What do professional devs do?
The reason I am asking is because I'm using multiple libraries with each having their own namespaces. It seems as things grow more complex that it is easier to read the code leaving the namespaces in - even if they are occasionally very long and common.
What do professional devs do?
Personally I don't ever use
I think the general rule of thumb is that it's fine to have
using. It's beyond me why they (ANSI) came up with it. IMO it's just a way for people to be lazy.I think the general rule of thumb is that it's fine to have
using in implementation files, but not in header files although I'm not sure why. I get slightly irritated whenever I see people use it at all. I think it's totally pointless, doesn't help at all, and without using it's easy to see where functions are coming from.
Last edited on
you can use
using namespace and make it local.. i mean only a part of code can use that namespace..
closed account (z05DSL3A)
Prefer Using Declarations to Using Directive but prefer full scope resolution to Using Declarations.
http://www.cplusplus.com/forum/beginner/9181/#msg42419
http://www.cplusplus.com/forum/beginner/9181/#msg42419
closed account (z05DSL3A)
Some say that repeating the full qualified name over and over again is tedious, error prone and less readable and that using declaration or using directive can be used to relieve the tedium, reduce the risk of error, and make the code easier to read.
Well, if the namespace was named something like
cpp_standard_functions_templates_and_variables_et_al I could understand; but std is 3 letters. For user-created and other namespaces, if the namespace name is too long, then they should change it.
Last edited on
@chrisname, don't forget, you can do stuff like
namespace std = namespace_of_standard_functions_to_be_used_with_the_cpp_standard_library;
Well, that just proves my point. If the namespace has a long name, you can do that.
Thanks, R0mai.
Thanks, R0mai.
Namespaces do two things:
1) They avoid name conflicts. For example, if you want to make a class or variable or something called "vector", it would normally conflict with <vector>'s vector. But since <vector>'s vector is in the std namespace, there's no conflict.
2) They make it easier to identify which library an identifier belongs to. IE:
With that in mind...
#2 is more of an aesthetic thing, and can never really be defeated -- it can only be made optional. You can still write "std::vector" when
Putting
Putting "using namespace" in a source (cpp) file isn't nearly as bad. Neither is putting it inside of a class body in a header. Though it still reintroduces the possibility of name conflicts. Unless you're sure you won't have any name conflicts, it's probably not a good idea. Note the only way to be 100% sure is to be aware of every identifier in the namespace and be sure you don't redefine those identifiers anywhere in your code (Do you know every single identifier in std? I sure don't). If you don't know all the identifiers in the namespace, you might end up with "surprise" conflicts.
Say for example you're "using namespace a;" because you want to use the a::jack class. Then you write you own jill class. Little did you know that namespace a also has a jill class, which means you just created a surprise conflict.
"using" individual identifiers (ie: "using std::cout;") is a lot safer since you won't have any "surprise" name conflicts like the above.
All of that said.. there's nothing wrong with using namespace std for quickie test projects or homework assignments. I wouldn't recommend putting it in a serious project though.
1) They avoid name conflicts. For example, if you want to make a class or variable or something called "vector", it would normally conflict with <vector>'s vector. But since <vector>'s vector is in the std namespace, there's no conflict.
2) They make it easier to identify which library an identifier belongs to. IE:
boost::shared_ptr makes it obvious you're using the boost library for the shared_ptr class. Likewise std::vector makes it obvious you're using the std library.With that in mind...
#2 is more of an aesthetic thing, and can never really be defeated -- it can only be made optional. You can still write "std::vector" when
using namespace std; if you feel it makes your code more clear.Putting
using namespace xxx; globally in a header is bad because it completely defeats #1. Remember that any new code can #include a header at a future time. So even if using namespace x doesn't introduce any name conflicts in your header it might introduce name conflicts in future cpp files you create (or even in existing ones).Putting "using namespace" in a source (cpp) file isn't nearly as bad. Neither is putting it inside of a class body in a header. Though it still reintroduces the possibility of name conflicts. Unless you're sure you won't have any name conflicts, it's probably not a good idea. Note the only way to be 100% sure is to be aware of every identifier in the namespace and be sure you don't redefine those identifiers anywhere in your code (Do you know every single identifier in std? I sure don't). If you don't know all the identifiers in the namespace, you might end up with "surprise" conflicts.
Say for example you're "using namespace a;" because you want to use the a::jack class. Then you write you own jill class. Little did you know that namespace a also has a jill class, which means you just created a surprise conflict.
"using" individual identifiers (ie: "using std::cout;") is a lot safer since you won't have any "surprise" name conflicts like the above.
All of that said.. there's nothing wrong with using namespace std for quickie test projects or homework assignments. I wouldn't recommend putting it in a serious project though.
My two cents: You should always feel a bit bad when using "using" - then it's ok to use it. :-D.
Never use it in header files which have some "library" - style, like your awesome ParticleEngine.h you want to use all over your code.
And if you use it in cpp's, the one and only reason should be to make code look a lot easier to read. Make sure that the code doesn't get worse to read instead, what can happen often when it's not crystal clear where the class came from.
E.g. I tend to import "string", as I never ever would implement a string by my own or use anything but the holy std::string-grail anyway. ;-)
There are some classes which were written with "using namespace" in mind, e.g. boost::lambda (which get obsolete with the lambda-language feature) and boost::bind (which will be soon in std namespace). It's just not the same to write "std::placeholders::_1" if it was meant to be just "_1" :-D
Ciao, Imi.
Never use it in header files which have some "library" - style, like your awesome ParticleEngine.h you want to use all over your code.
And if you use it in cpp's, the one and only reason should be to make code look a lot easier to read. Make sure that the code doesn't get worse to read instead, what can happen often when it's not crystal clear where the class came from.
E.g. I tend to import "string", as I never ever would implement a string by my own or use anything but the holy std::string-grail anyway. ;-)
There are some classes which were written with "using namespace" in mind, e.g. boost::lambda (which get obsolete with the lambda-language feature) and boost::bind (which will be soon in std namespace). It's just not the same to write "std::placeholders::_1" if it was meant to be just "_1" :-D
Ciao, Imi.
Topic archived. No new replies allowed.