StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p><em>Revisited and summarised</em></p> <p><strong>Option 1</strong></p> <p>You may simply declare and define a global instance of Game object. In a header file, e.g. game.h:</p> <pre><code>extern Game globalGameObj; </code></pre> <p>When you include game.h in a source file globalGameObj name becomes visible. You also need to create an actual object. In a source file, e.g. game.cc (outside of any class):</p> <pre><code>Game globalGameObj; </code></pre> <p>Access it by the variable name:</p> <pre><code>globalGameObj.do_some_work(); </code></pre> <p><strong>Option 2</strong></p> <p>Use a pattern often called singleton. Add the following to your Game class (game.h):</p> <pre><code>class Game { public: static Game &shared_instance() {static Game game; return game;} private: // Make constructor private. Only shared_instance() method will create an instance. Game() {/*whatever initialisation you need*/} }; </code></pre> <p>You access Game instance with shared_instance() method:</p> <pre><code>Game::shared_instance().go_some_work(); </code></pre> <p>You do not use anything like your <code>static class PublicInstances</code> in the above. C++ allows you to introduce a namespace (e.g. PublicInstances) to provide name isolation and keep your global objects in one place but it'll probably to be an overkill. In any case if you have few global objects then it is likely to be a bad design.</p> <p>What option is better? Some people would argue that singleton pattern should be used. It guarantees that only a single instance is created. However both option 1 and option 2 have the same problem: they introduce a global object in your code with all disadvantages attributed to global variables. I'd say that singleton is a global object in disguise. I do not see deciding technical reasons in favour of either option so I'd say that it is a matter of personal taste.</p> <p><strong>Historical note :)</strong></p> <p>My first suggestion for Option 2 was to use a dynamically allocated Game object rather than a function local static object.</p> <pre><code>static Game *instance() {if (!_inst) _inst = new Game(); return _inst;} </code></pre> <p>Few people suggested that it was not the best way anymore, thank you <a href="https://stackoverflow.com/users/2697746/kal">Kal</a>, <a href="https://stackoverflow.com/users/1860449/argiopeweb">argiopeweb</a> and <a href="https://stackoverflow.com/users/2491746/simple">Simple</a>. C++03 has issues initialising static objects in presence of threads. C++11 guarantees safe initialisation of statics.</p> <p>C++11 draft, secion 6.7</p> <pre><code>such a variable is initialized the first time control passes through its declaration; such a variable is considered initialized upon the completion of its initialization. [...] If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization. </code></pre>

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