StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PONamespaces vs. Static Classes
text
Body
copied!<p>For a project I'm working on, I have a bunch of "library classes". These are essentially collections of related functions of values. Some of these libraries need to be "initialized" at run-time. So far, I've been utilizing the design below as a solution:</p> <pre><code>// Filename: Foo.h namespace my_project { namespace library { class Foo { public: static int some_value; // members used externally and internally Foo() { // Lots of stuff goes on in here // Therefore it's not a simply member initialization // But for this example, this should suffice some_value = 10; Foo::bar(); } static void bar() { ++some_value; } // some library function // no destructor needed because we didn't allocate anything private: // restrict copy/assignment Foo(const Foo&); void operator=(const Foo&); }; int Foo::some_value = 0; // since some_value is static, we need this } // library namespace static library::Foo Foo; } // my_project namespace </code></pre> <p>Using <code>Foo</code> would be similar to this, as an example:</p> <pre><code>#include "Foo.h" using namespace my_project; int main() { int i = Foo.some_value; Foo.bar(); int j = Foo.some_value; return 0; } </code></pre> <p>Of course, this example is very simplified, but it gets the point across. This method has four advantages to me:</p> <ol> <li><p>User of the library doesn't need to worry about initialization. They wouldn't need to call something like <code>Foo::init();</code> inside their <code>main()</code>, because <code>library::Foo</code> was initialized when <code>my_project::Foo</code> was constructed. This is the main design constraint here. <em>User should <strong>not</strong> be responsible for initializing the library.</em></p></li> <li><p>I can create various private functions inside the library to control its use.</p></li> <li><p>The user can create other instances of this library if they choose, for whatever reason. But no copying would be allowed. One instance would be provided for them by default. This is a requirement.</p></li> <li><p>I can use the <code>.</code> syntax instead of <code>::</code>. But that's a personal style thing.</p></li> </ol> <p>Now, the question is, are there any disadvantages to this solution? I feel like I'm doing something that C++ wasn't meant to do because Visual Studio's IntelliSense keeps freaking out on me and thinks <code>my_project::Foo</code> isn't declared. Could it be because both the object and the class are called <code>Foo</code> even though they're in different namespaces?</p> <p>The solution compiles fine. I'm just worried that once my project grows larger in scale, I might start having name ambiguities. Furthermore, am I wasting extra memory by creating an object of this library?</p> <p>Should I simply stick to the <a href="http://en.wikipedia.org/wiki/Singleton_pattern" rel="nofollow">singleton design pattern</a> as an alternative solution? Are there any alternative solutions?</p> <p><strong>UPDATE:</strong></p> <p>After reviewing the solutions provided, and jumping around google for various solutions, I stumbled upon <code>extern</code>. I have to say I'm a bit fuzzy on what this keyword really does; I've been fuzzy about it ever since I learned C++. But after tweaking my code, I changed it to this:</p> <pre><code>// Foo.h namespace my_project { namespace library { class Foo_lib { public: int some_value; Foo_lib() { /* initialize library */ } void bar() { /* do stuff */ } private: // restrict copy/assignment Foo_lib(const Foo_lib&); void operator=(const Foo_lib&); }; } // library namespace extern library::Foo_lib Foo; } // my_project namespace // Foo.cpp #include "Foo.h" namespace my_project { namespace library { // Foo_lib definitions } // library namespace library::Foo_lib Foo; } // my_project namespace // main.cpp #include "Foo.h" using namespace my_project; int main() { int i = Foo.some_value; Foo.bar(); int j = Foo.some_value; return 0; } </code></pre> <p>This seems to have the exact same effect as before. But as I said, since I'm still fuzzy on extern usage, would this also have the exact same bad side-effects?</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload