[ACCEPTED]-Should I wrap all my c++ code in its own namespace?-namespaces

Many C++ developers do not use namespaces, sadly. When 29 I started with C++, I didn't use them for 28 a long time, until I came to the conclusion 27 that I can do better using namespaces.

Many 26 libraries work around namespaces by putting 25 prefixes before names. For example, wxWidgets 24 puts the characters "wx" before everything. Qt 23 puts "Q" before everything. It's nothing 22 really wrong with that, but it requires 21 you to type that prefix all over again, even 20 though when it can be deduced from the context 19 which declarations you mean. Namespaces 18 have a hierarchic order. Names that are 17 lexically closer to the point that reference 16 them are found earlier. So if you reference 15 "Window" within your GUI framework, it will 14 find "my::gui::Window", instead of "::Window".

Namespaces 13 enable some nice features that can't be 12 used without them. For example, if you put 11 your class into a namespace, you can define 10 free functions within that namespace. You 9 then call the function without putting the 8 namespace in front by importing all names, or 7 selectively only some of them into the current 6 scope ("using declaration").

Nowadays, I 5 don't do any project anymore without using 4 them. They make it so easy not to type the 3 same prefix all over again, but still have 2 good organization and avoidance of name-pollution 1 of the global namespace.

Depends, if your code is library code, please 8 wrap it in namespaces, that is the practice 7 in C++. If your code is only a very simple 6 application that doesn't interact with anything 5 else, like a hello world sort of app, there 4 is no need for namespaces, because its redundant.

And 3 since namespaces aren't required the code 2 snippets and examples on the web rarely 1 use them but most real projects do use them.

I just discovered Google's c++ style guide 2 and they have namespace guidelines.

The whole guide is worth reading, but 1 to summarize, they say:

• Add unnamed namespaces to .cc files, but not .h files.
• Wrap entire (after includes/declarations) .cc and .h files in named namespaces.
• Namespaces do not increment the indent level.
• At the closing brace for a namespace write } // namespace.
• Don't declare anything in std, because it is undefined.
• using the using directive is forbidden.
• the using declaration is allowed in functions, methods, and classes.
• namespace aliases are allowed anywhere.

It really depends upon whether you expect 12 there to be any conflicts.

Two scenarios;

1) If 11 you are creating code that may be used by 10 others (e.g libraries) then there could 9 be namespace clashes so using your own namespace 8 is a good idea.

2) If you are using third-party 7 libraries their code may not be namespaced 6 and could conflict with yours.

I would also 5 say that if you expect your code to be sizable 4 and cover many different areas (math/physics/rendering) then 3 using namespaces does make the code easier 2 to grok, particularly for types that are 1 not obviously classified.

We had problems wrapping code in managed 6 C++ that uses our common libraries here.

Some 5 classes had the same names as System class 4 in the .NET library (i.e. System.Console).
We 3 had to do some ugly macro patches to workaround 2 these problems.

Using namespaces at the beginning 1 would have prevented this.

You only really need namespaces if there's 8 a risk of names conflict - some globally 7 seen function or variable or class is defined 6 more than once. Otherwise you'll do just 5 fine with no namespace - just name your 4 classes so that they don't duplicate runtime 3 library classes and make global functions/variable 2 to be static members of some reasonable 1 classes.

but this practice appears to be uncommon 4 in the c++ world

Really. All the code I see 3 seems to be wrapped in a namespace.
I use 2 the same type of convention I see in Java 1 (except I drop the com).

In Java

package com.<Company>.<Product>.<Package>;

In C++

namespace <Company>
{
     namespace <Product>
     {
         namespace <Package>
         {
         }
     }
 }

I'd say that it's a good idea, if for no 7 other reason than to keep your stuff from 6 getting stepped on when mixed with other 5 third-party code.

I try to go even farther 4 than that by putting as many variables and 3 functions as I can into classes. But that's 2 sometimes harder to do than it should be 1 (compared to other OO languages).