> The good news is that you do NOT need to wrap/expose non canonical > objects. A more reliable, flexible, sounder pattern is to wrap > and expose "lightweight proxy" C++ objects -- that will internally > delegate whatever is needed to your "one and only substantial > object", but will NOT implement the singleton Design Pattern with > the attendant efforts to ensure only one of them is ever subject > to instantiation (whence the need to avoid copying, etc, etc, and > hence the non-canonicality). ... > Over the last week or so, the singleton DP came up for discussion > a couple of times on this group -- I seem to be in a tiny minority > in disliking it intensely in favour of featherweight proxies, though > I know I'm NOT the only one since I recall a C++ Report article > that made points very similar to mine. www.google.com/groups should > let you fetch and read the few relevant articles for background. Just to add my support to Alex here - we haven't always agreed on everything (c.f. ''.join() ;) but I'm in complete agreement in this case. Flyweight is a *very* useful design pattern, whilst *public* Singleton is incredibly difficult to enforce. You are best to have a private Singleton (i.e. it is only visible to your code) and expose its interface via a Flyweight. Simplest way to do this would be to have a non-static class only declared and implemented and instantiated in the implementation (.cpp) file where your Flyweight class is implemented. I think (been a while since I've done any C++ work). Tim Delaney
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4