'using namespace' or 'namespace::'?

Started by
13 comments, last by phresnel 15 years, 5 months ago
I've seen a lot of code that does:


using namespace ...;

and then uses whatever classes, functions, globals that are in that namespace. on the other hand, I have also seen a lot of code that does:


namespace::object

but what is considered better practice? I know that if you are wanting to use two namespaces that have the same object names in them, then the second way would be the way to go, but it can also make your code unreadable and messy when you prefix everthing with NameSpace:: especially when you have nested namespaces.
Advertisement
The rule is: don't put "using" directives in a header file.

In a source file, use whatever is cleaner. I found though that once I started writing the fully qualified names in the header, I started to use it almost universally.

For nested namespaces, I believe you can do the following:
namespace shortcut = silly::number::of::nested::namespaces;// use shortcut::foo
Our local style is to use "namespace::" in headers, to avoid making namespaces useless, and "using namespace" in cpp files, until there is a problem. Namespace clashes seem to be rare enough that this policy works very well for us.
thanks, that cleared things up.
Is it better to refer to my friend Jerry as "my friend Jerry", or to make it clear from context that all the people I'm talking about are my friends, and then just call him by name?

It depends.

If one were clearly preferable to the other, you wouldn't be able to do both.

The reason we use (that we *have*) namespaces, instead of tagging things manually with prefixes (thus foo::bar instead of foo_bar), is that we can omit the prefixes when there would be no ambiguity. Writing it every time makes things ugly, but you have to consider whether going too far the other way would make things difficult either for the compiler (by causing name collisions) or the reader (by making it hard to figure out where names come from).
Another point you might want to look out for (which may or may not be applicable to you). If you stick to the notion that 'using namespace' is ok in .cpp files but not in .h files, then this logic can be faulty if you are using a unity build system (where you don't compile the individual .cpp files, but include each .cpp file in one .cpp file which is then compiled).
Quote:Original post by _moagstar_
Another point you might want to look out for (which may or may not be applicable to you). If you stick to the notion that 'using namespace' is ok in .cpp files but not in .h files, then this logic can be faulty if you are using a unity build system (where you don't compile the individual .cpp files, but include each .cpp file in one .cpp file which is then compiled).


Why on earth would you do that do yourself?
if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight
Quote:Original post by ChaosEngine
Quote:Original post by _moagstar_
Another point you might want to look out for (which may or may not be applicable to you). If you stick to the notion that 'using namespace' is ok in .cpp files but not in .h files, then this logic can be faulty if you are using a unity build system (where you don't compile the individual .cpp files, but include each .cpp file in one .cpp file which is then compiled).


Why on earth would you do that do yourself?


The single most compelling argument for monolithic .cpp files (and the reason we use something similar at work) is build time improvements. By building your entire project in a single compilation unit, you can insure that header files are included only once and therefor you are not building the same code in many compilation units.

This technique cut full build times for me from 45-60 minutes to around 10. The tradeoff is slightly increased incremental build times, but it's well worth it (for me, YMMV).
Our friend Cylon tells us (##c++ @ freenode):
00:34 < exDM69_> !using namespace00:34 < nolyc> The use of using-directives (e.g. `using namespace std;') is                discouraged, because: (1) in the case of namespace std, it                potentially brings hundreds of names from the entire standard                library into scope, and (2) their use obscures the origins of                unqualified names in your code. Use explicit qualification (e.g.                `std::cout') and/or using-declarations (e.g. `using std::cout;')                instead.


Quote:Original post by Zahlman
The reason we use (that we *have*) namespaces, instead of tagging things manually with prefixes (thus foo::bar instead of foo_bar), is that we can omit the prefixes when there would be no ambiguity. Writing it every time makes things ugly, but you have to consider whether going too far the other way would make things difficult either for the compiler (by causing name collisions) or the reader (by making it hard to figure out where names come from).


Namespaces are a bit more than that (albeit nowhere near a real module system). Combined with Koenig lookup (search for function in the namespaces of their arguments) and some generic programming, namespaces have significant advantages over a plain old naming prefix. Good examples that use this are std::min and std::abs. (btw, you should always do using std::min; min(x); instead of std::min(x) if the code is in a template and x is of unknown type).

My guideline is as follows: I almost always do std::, quite often I do using boost::bind and sometimes even using namespace boost::lambda and I always do namespace po = boost::program_options when I encounter annoyingly long namespace names. I always try to stick with the innermost scope, and very seldom do anything outside a function-bound scope. I usually name my own namespaces with 3-5 letter names.

-Riku
Quote:Original post by Driv3MeFar
Quote:Original post by ChaosEngine
Quote:Original post by _moagstar_
Another point you might want to look out for (which may or may not be applicable to you). If you stick to the notion that 'using namespace' is ok in .cpp files but not in .h files, then this logic can be faulty if you are using a unity build system (where you don't compile the individual .cpp files, but include each .cpp file in one .cpp file which is then compiled).


Why on earth would you do that do yourself?


The single most compelling argument for monolithic .cpp files (and the reason we use something similar at work) is build time improvements. By building your entire project in a single compilation unit, you can insure that header files are included only once and therefor you are not building the same code in many compilation units.

This technique cut full build times for me from 45-60 minutes to around 10. The tradeoff is slightly increased incremental build times, but it's well worth it (for me, YMMV).


"Slightly" increased incremental build times? In this approach every time you make any change to a single line of code, you have to rebuild your entire project! Admittedly that rebuild will be faster, but precompiled header files are a much more elegant solution to that problem.

As you said, this works for you, but I really don't see how. I would generally only rebuild for a release (or if there's some weird compilation issue), but when debugging, I might build 10 times an hour. The tradeoff simply wouldn't be worth it for me (but as you said, YMMV).

if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

This topic is closed to new replies.

Advertisement