If you must, here is some code:

http://www.geocities.com/jeff_louie/OOP/oop40.htm

Regards,
Jeff

I like the "if you must" ;-)

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

*************************************************
| Think outside the box!
|
*************************************************
[quoted text, click to view]

Hi Gregory... It goes with my programming maxim "Just because you can do
something, does not mean you should do it." :)

Regards,
Jeff

[quoted text, click to view]

One disadvantage to this approach is that the implicit protocol for
subclasses can be circumvented. I could subclass OnlyMaleAnimal and
provide a public constructor making it possible to have many different
instances of OnlyMaleAnimal. If the class hierarchy represented some
kind of security data structure that could be a potential security

Brian.. Good point, as this pattern only provides a weak singleton
guarantee. As I noted in the code, there is no strong singleton
guarantee with this pattern due to the possibility of concurrency
conflicts during registration, so that more than one instance of the
base class could be created if more than one subclass read the registry
at "almost exactly the same time." Only one instance would be
successfully registered, however, and the base class "global point of
access" would only return a reference to a single instance or throw.

I have now added a note pointing out that a poorly designed subclass
could also lead to more than one instance of the base class.

Regards,
Jeff