Library Idea
Global Object Manager – GOM – aka Singleton


by gsf


I have code that deals with problems related to initialization of global objects (singletons).
1. Multi-threading – problems occurring in some singleton patterns based on the fact that local for a function or method static variables are not initialized in a thread safe manner
2. Initialization order – there is no multi-platform/multi-compiler standard way to control the global objects initialization order
3. Static linking of global objects code without need – some patterns result in global objects to be linked in the final executable, even if they are provided from static libraries and the code that uses them is not in use
4. Capability for easy replacement of a global implementation object with a mock object

I was struggling with shutdown issues in complex c++ application for years in several different projects. With the solution I come up a few years ago I have no issues in any project I have used it.

Note that the boost singleton pattern used for path_locale (boost filesystem path) is having the multi-thread issue I mentioned in point 1. This is a small test that demonstrates the problem: https://github.com/ggeorgiev/boost-filesystem-singletons/blob/master/filesystem-test/main.cpp

The code of the library is in: https://github.com/ggeorgiev/gom


There are 3 comments

Comment on This Page

  • Robert Ramey says:

    I'm referring to https://github.com/boostorg/serialization/blob/master/include/boost/serialization/singleton.hpp . Also there is another one in boost memory pool. I'm not in a position to really spend time studying this. But you don't need me!!! If you prepare your library to the standards of the Boost Library Incubator, (They aren't too rigorous), You library will be exposed to lots of people who are looking for something like this. You may get feed back from them. At least that's the idea of this website! One thing, you might want to consider using the name "Singleton" in the library name as many people would instantly recognize the purpose of the library. Good luck with this!

  • gsf says:

    I assume you reference https://github.com/boostorg/serialization/blob/master/include/boost/serialization/singleton.hpp

    If yes, please review my code if you find some time. GOM is not a base class for a singletons. My proposal solves a way bigger set of issues related to singletons with approaching the problem differently.

  • Robert Ramey says:

    By a huge coincidence, I was thinking out about exactly this topic this weekend. Here is a little background information.

    In 2008 a Singleton class was presented for review by boost. I can't find the source now but you can find all the discussion at
    http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2553779&query=singleton+review&i=12

    The class was rejected for inclusion into boost. At the time, I was in need of such a component for the serialization library (inspired by loki) so I made my own and stored as part of the serialization library. It also turns out that at least one other boost library – memory pool – did something similar. So it would seem that this is a good candidate for a boost library.
    As I write this, there is no reviewed and accepted Singleton class in boost.

    Should you decide to submit your own, I hope you find the information on this site useful.