Mikhail Glushenkov wrote:
What about adapting Loki's Singleton? It's the best Singleton I know about and (probably) the most widely-known one.
I agree that it is probably one of the best ones around. My only issues are: 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. 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. 3) What issues are there with the licensing of Loki? David Greene wrote:
I think that's a good place to start. What other patterns should we be looking at. We ought to start a wiki page.
I would prefer to put the files in the sandbox so they are versioned, have history, etc. The yahoo files section is inconvenient due to the registration requirement.
I would be happy to submit what I have to the sandbox - who do I contact to get on the sandbox as a developer, and is there a set of submission guidelines? Where would the wiki page be? I also notice from a quick browse of the sandbox that there is a set of classes for visitors, and that they haven't really been touched for 2 years. Did these ever make it into boost? Is there any documentation for them? And could we perhaps look there for a starting point for the visitor side of things? In my view, the best start for a list of patterns to look at is probably the GoF book! I have written generic code in the past for: 1) Flyweights 2) Composites 3) Visitors 4) Singletons 5) Bridge (just to link the 2 classes easily) There is certainly scope to include: 1) Factory Method 2) Abstract Factory 3) Decorator 4) Chain of responsibility However, if we are to have a go at a project like this, I would suggest keeping the initial submission list quite short, and then if there is some interest further down track, follow on with more patterns. Dave