'Helper' functions in C++

Question

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 other member functions and b) because they might prove useful elsewhere.

This led me to think about the best way to group 'helper' functions together. The Java/C# way would be to use a class of static functions with a private constructor, e.g.:

class Helper  
{  
private:  
  Helper() { }
public:  
  static int HelperFunc1();  
  static int HelperFunc2();  
};

However, being C++ you could also use a namespace:

namespace Helper  
{  
  int HelperFunc1();  
  int HelperFunc2();  
}

In most cases I think I would prefer the namespace approach but I wanted to know what the pros and cons of each approach are. If used the class approach for example, would there be any overheads?

Answer 1

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.

Answer 2

Overhead is not an issue, namespaces have some advantages though

• You can reopen a namespace in another header, grouping things more logically while keeping compile dependencies low

• 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
  

Answer 3

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.

Edit from paercebal

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.

Answer 4

Namespaces offer the additional advantage of Koenig lookup. Using helper classes may make your code more verbose - you usually need to include the helper class name in the call.

Another benefit to namespaces is in readability later on. With classes, you need to include words like "Helper" to remind you later that the particular class isn't used to create objects

In practice, there's no overhead in either. After compilation, only the name mangling used differs.

Answer 5

One 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;
}

Answer 6

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.

Answer 7

Copied/trimmed/reworked part of my answer from http://stackoverflow.com/questions/41590/how-do-you-properly-use-namespaces-in-c#81602.

Using "using"

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
}

Namespace Composition

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.