While refactoring some old code I have stripped out a number of public methods that should actually of been statics as they a) don\'t operate on any member data or call any othe
Overhead is not an issue, namespaces have some advantages though
You can use namespace aliasing to your advantage (debug/release, platform specific helpers, ....)
e.g. I've done stuff like
namespace LittleEndianHelper {
void Function();
}
namespace BigEndianHelper {
void Function();
}
#if powerpc
namespace Helper = BigEndianHelper;
#elif intel
namespace Helper = LittleEndianHelper;
#endif
I tend to use anonymous namespaces when creating helper functions. Since they should (generally) only be seen by the module that cares about them, its a good way to control dependencies.
A case where one might use class
(or struct
) over namespace
is when one needs a type, for example:
struct C {
static int f() { return 33; }
};
namespace N {
int f() { return 9; }
}
template<typename T>
int foo() {
return T::f();
}
int main() {
int ret = foo<C>();
//ret += foo<N>(); // compile error: N is a namespace
return ret;
}
To add to Pieter's excellent response, another advantage of namespaces is that you can forward declare stuff that you put in a namespace somewhere else, especially structs...
//Header a.h
// Lots of big header files, spreading throughout your code
class foo
{
struct bar {/* ... */);
};
//header b.h
#include a.h // Required, no way around it, pulls in big headers
class b
{
//...
DoSomething(foo::bar);
};
And with namespaces...
//Header a.h
// Big header files
namespace foo
{
struct bar {/* ... */);
}
//header b.h
// Avoid include, instead forward declare
// (can put forward declares in a _fwd.h file)
namespace foo
{
struct bar;
}
class b
{
//...
// note that foo:bar must be passed by reference or pointer
void DoSomething(const foo::bar & o);
};
Forward declares make a big difference to your compile times after small header changes once you end up with a project spanning hundreds of source files.
The answer was too good to let it die because of an enum error (see comments). I replaced enums (which can be forward-declared only in C++0x, not in today C++) by structs.
The main advantage to using a namespace is that you can reopen it and add more stuff later, you can't do that with a class. This makes this approach better for loosely coupled helpers (for example you could have a Helpers namespace for your entire library, much like all of STL is in ::std)
The main advantage of a class is that you can nest it inside the class using it, you can't nest a namespace in a class. This makes this approach better for tightly coupled helpers.
You won't have any extra overhead having them in a class vs a namespace.
Copied/trimmed/reworked part of my answer from How do you properly use namespaces in C++?.
You can use "using" to avoid repeating the "prefixing" of your helper function. for example:
struct AAA
{
void makeSomething() ;
} ;
namespace BBB
{
void makeSomethingElse() ;
}
void willCompile()
{
AAA::makeSomething() ;
BBB::makeSomethingElse() ;
}
void willCompileAgain()
{
using BBB ;
makeSomethingElse() ; // This will call BBB::makeSomethingElse()
}
void WONT_COMPILE()
{
using AAA ; // ERROR : Won't compile
makeSomething() ; // ERROR : Won't compile
}
Namespaces are more than packages. Another example can be found in Bjarne Stroustrup's "The C++ Programming Language".
In the "Special Edition", at 8.2.8 Namespace Composition, he describes how you can merge two namespaces AAA and BBB into another one called CCC. Thus CCC becomes an alias for both AAA and BBB:
namespace AAA
{
void doSomething() ;
}
namespace BBB
{
void doSomethingElse() ;
}
namespace CCC
{
using namespace AAA ;
using namespace BBB ;
}
void doSomethingAgain()
{
CCC::doSomething() ;
CCC::doSomethingElse() ;
}
You could even import select symbols from different namespaces, to build your own custom namespace interface. I have yet to find a practical use of this, but in theory, it is cool.