Jump to content
  • Advertisement
Sign in to follow this  
staticVoid2

'using namespace' or 'namespace::'?

This topic is 3601 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

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Our friend Cylon tells us (##c++ @ freenode):

00:34 < exDM69_> !using namespace
00: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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!