I realize now that there is little interest in considering my library for Boost over an adaptation of the Loki library... however, even if my implementation is not under consideration, would someone be willing to explain what advantages Loki offers over it? Dave Handley wrote:
1) Wouldn't it be better to use CRTP than the rather strange usage syntax that Loki uses with a typedef and a requirement to make the constructors/destructors private? It is remarkably easy if you are not familiar with the Singleton implementation in Loki to make your constructors/destructors public by mistake and then use them, whereas a CRTP solution could make the base constructors/destructors protected.
With my implementation it is perfectly safe for client code to make public constructors and destructors and not have to worry about the class being used the wrong way, because the inheritance method I used makes it pure virtual.
2) There are probably some more options that need to be included, for example making a Singleton be capable of destroying/recreating during the run of a program. Consider a singleton that is managing a print queue. For some reason all the printers go off-line, there is a potential for memory optimisation by closing down the print queue. If printers come back on line the print queue could come back on line - but that isn't possible (as far as I know) with Loki.
With my revised usage of dependencies, the singleton would be destroyed when there were no dependencies left and recreated when new ones were added. If client code wants to ensure that the singleton's life is not interrupted, they could add a dependency in main, or even add a static/global dependency to ensure that the lifetime extends beyond main if that feature is desired. Using dependencies also can ensure that singletons which rely on each other are always created and destroyed in the right order. Again, I am unfamiliar with Loki, so I am sure that there are considerations that it handles of which I am unaware. I would just like to learn what these considerations are so that I might grow as a programmer, and learn through improving my own implementation. Thanks in advance. -Jason Link posted for reference: http://www.ezequal.com/chaos/libs/singleton_revised.h Notice: There was a message that I posted two days ago that seemed to have been lost... it is probably obsolete and repetitive now, but it is attached should anyone care to read it. Dave Handley wrote:
Ordering of Singletons is, in my opinion, one of the most important issues with Singletons. It is almost
certainly insufficient in most applications to create in a specific order, and delete in reverse order. One reason for this is start-up performance - you don't want every Singleton to have to create at startup (necessarily). Another reason can be memory efficiency. Loki again provides a number of policies including a Phoenix Singleton and a Longevity managed singleton. I personally tend to use Longevity managed singletons linked to the at_exit function. Nevertheless, there are some additional things that I would like to see - for example, a phoenix singleton that could be created and destroyed more than once during a program run could be useful - either explicitly or even if not used for a while. Also, allowing thread-safety as an option is also crucial. The way that my design works is to use reference counting in the form of dependency objects, which create the singleton when the first dependency is constructed and destroy the singleton when the last dependency is destroyed. If a singleton A owns a dependency on singleton B, that dependency lifetime will be greater than the lifetime of A itself, meaning that B will exist for the duration of A's lifetime. The only property of my singleton that forces it to be constructed before main and destructed after is the existence of a static dependency in the singleton class to itself. If I removed this static dependency, it would allow for singletons that could be created and destroyed any number of times, and lifetime would be completely controlled by the scope at which the dependencies lived. Implementing this change would make it possible for GetInst to fail, when it would be more desirable to have GetInst somehow utilize a dependency itself. Perhaps I could enable this by having GetInst return a type of smart pointer, which would own a singleton dependency as well as pointing to the singleton object. Thoughts / suggestions? I have no experience in dealing with thread safety. Would ensuring thread safety require that the singleton have access to a threading library, or would it be possible to just write the code more carefully to ensure safety, similar to writing exception safe code? In addition, I have no familiarity with the other design patterns you mentioned, nor with Loki. I learned about the singleton concept through a friend and thought that it made for an interesting challenge. I just ordered Modern C++ Design, so hopefully I can familiarize myself with these topics in the near future. For reference, I will leave a link to the code below: http://www.ezequal.com/chaos/libs/singleton.h