<p>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.</p>

<p>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.:</p>

<pre><code>class Helper  
{  
private:  
  Helper() { }
public:  
  static int HelperFunc1();  
  static int HelperFunc2();  
};
</code></pre>

<p>However, being C++ you could also use a namespace:</p>

<pre><code>namespace Helper  
{  
  int HelperFunc1();  
  int HelperFunc2();  
}
</code></pre>

<p>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?</p>

[{'answer_id': 80636, 'author': 'Don Neufeld', 'author_id': 13097, 'author_profile': 'https://Stackoverflow.com/users/13097', 'pm_score': 2, 'selected': False, 'text': "<p>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)</p>\n\n<p>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.</p>\n\n<p>You won't have any extra overhead having them in a class vs a namespace.</p>\n"}, {'answer_id': 80651, 'author': 'Pieter', 'author_id': 5822, 'author_profile': 'https://Stackoverflow.com/users/5822', 'pm_score': 6, 'selected': True, 'text': "<p>Overhead is not an issue, namespaces have some advantages though</p>\n\n<ul>\n<li>You can reopen a namespace in another header, grouping things more logically while\nkeeping compile dependencies low</li>\n<li><p>You can use namespace aliasing to your advantage \n(debug/release, platform specific helpers, ....)</p>\n\n<p>e.g. I've done stuff like</p>\n\n<pre><code>namespace LittleEndianHelper {\n   void Function();\n}\nnamespace BigEndianHelper {\n   void Function();\n}\n\n#if powerpc\n   namespace Helper = BigEndianHelper;\n#elif intel\n   namespace Helper = LittleEndianHelper;\n#endif\n</code></pre></li>\n</ul>\n"}, {'answer_id': 80804, 'author': 'Tom Leys', 'author_id': 11440, 'author_profile': 'https://Stackoverflow.com/users/11440', 'pm_score': 3, 'selected': False, 'text': "<p>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...</p>\n<pre><code>//Header a.h\n// Lots of big header files, spreading throughout your code\nclass foo\n{\n  struct bar {/* ... */);\n};\n\n//header b.h\n#include a.h // Required, no way around it, pulls in big headers\nclass b\n{\n  //...\n  DoSomething(foo::bar);\n};\n</code></pre>\n<p>And with namespaces...</p>\n<pre><code>//Header a.h\n// Big header files\nnamespace foo\n{\n  struct bar {/* ... */);\n}\n\n//header b.h\n// Avoid include, instead forward declare \n//  (can put forward declares in a _fwd.h file)\nnamespace foo\n{\n  struct bar;\n}\n\nclass b\n{\n  //...\n  // note that foo:bar must be passed by reference or pointer\n  void DoSomething(const foo::bar &amp; o);\n};\n</code></pre>\n<p>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.</p>\n<h2>Edit from paercebal</h2>\n<p>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.</p>\n"}, {'answer_id': 81316, 'author': 'MSalters', 'author_id': 15416, 'author_profile': 'https://Stackoverflow.com/users/15416', 'pm_score': 2, 'selected': False, 'text': '<p>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.</p>\n\n<p>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</p>\n\n<p>In practice, there\'s no overhead in either. After compilation, only the name mangling used differs.</p>\n'}, {'answer_id': 88965, 'author': 'jwfearn', 'author_id': 10559, 'author_profile': 'https://Stackoverflow.com/users/10559', 'pm_score': 4, 'selected': False, 'text': '<p>A case where one might use <code>class</code> (or <code>struct</code>) over <code>namespace</code> is when one needs a type, for example:</p>\n\n<pre><code>struct C {\n  static int f() { return 33; }\n};\n\nnamespace N {\n  int f() { return 9; }\n}\n\ntemplate&lt;typename T&gt;\nint foo() {\n  return T::f();\n}\n\nint main() {\n  int ret = foo&lt;C&gt;();\n//ret += foo&lt;N&gt;(); // compile error: N is a namespace\n  return ret;\n}\n</code></pre>\n'}, {'answer_id': 92517, 'author': 'Greg Rogers', 'author_id': 5963, 'author_profile': 'https://Stackoverflow.com/users/5963', 'pm_score': 2, 'selected': False, 'text': '<p>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.</p>\n'}, {'answer_id': 383365, 'author': 'paercebal', 'author_id': 14089, 'author_profile': 'https://Stackoverflow.com/users/14089', 'pm_score': 2, 'selected': False, 'text': '<p>Copied/trimmed/reworked part of my answer from  <a href="https://stackoverflow.com/questions/41590/how-do-you-properly-use-namespaces-in-c#81602">How do you properly use namespaces in C++?</a>.</p>\n\n<h2>Using "using"</h2>\n\n<p>You can use "using" to avoid repeating the "prefixing" of your helper function. for example:</p>\n\n<pre><code>struct AAA\n{\n   void makeSomething() ;\n} ;\n\nnamespace BBB\n{\n   void makeSomethingElse() ;\n}\n\nvoid willCompile()\n{\n   AAA::makeSomething() ;\n   BBB::makeSomethingElse() ;\n}\n\nvoid willCompileAgain()\n{\n   using BBB ;\n\n   makeSomethingElse() ; // This will call BBB::makeSomethingElse()\n}\n\nvoid WONT_COMPILE()\n{\n   using AAA ; // ERROR : Won\'t compile\n\n   makeSomething() ; // ERROR : Won\'t compile\n}\n</code></pre>\n\n<h2>Namespace Composition</h2>\n\n<p>Namespaces are more than packages. Another example can be found in Bjarne Stroustrup\'s "The C++ Programming Language".</p>\n\n<p>In the "Special Edition", at <strong>8.2.8 Namespace Composition</strong>, 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:</p>\n\n<pre><code>namespace AAA\n{\n   void doSomething() ;\n}\n\nnamespace BBB\n{\n   void doSomethingElse() ;\n}\n\nnamespace CCC\n{\n   using namespace AAA ;\n   using namespace BBB ;\n}\n\nvoid doSomethingAgain()\n{\n   CCC::doSomething() ;\n   CCC::doSomethingElse() ;\n}\n</code></pre>\n\n<p>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.</p>\n'}]
['https://Stackoverflow.com/questions/80619', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/9236/']