RE: [boost] Re: Work in progress list? And how about a singleton?

From: scleary_at_[hidden]
Date: 2001-11-13 16:52:09

> Steve, what are your feelings on all this? Seeing as how you started a
> singleton class already, do you feel you have the time to incorporate
> these things into your design? Or would you rather I began work on a more
> general singleton from 'scratch'?

My current singleton would look very different once I remove that
restriction (by using an exception-neutral equivalent of boost::call_once).
We might just want to start from scratch.

Following are some comments on Gennadiy's list of recommended policies:

> > Here [is] what I think we need to make a really reusable singleton.
> > 1. Way the singleton is instantiated

I disagree; this is an implementation detail, except for the last one
"variable in thread-specific storage" which I see as a totally different
type of object -- not a singleton at all.

> > 2. When singleton is created

Do we need all these options?  Static vs. dynamic memory is an
implementation issue.  Just have it created at the point of first access,
and if the user wants to create it at a certain point (before main() or any
other point), just let him call "instance()".

> > 3. How singleton is created

I've thought about this a bit, but there's not a "nice" way to pass
constructor arguments to a singleton (meaning other than in every call to
"instance()").  In fact, I can't think of a single case where this would be
useful -- a singleton object really can't depend on anything other than
other singletons.

> > 4. Way the singleton is accessed

My simple answer is: by reference; all the other return types can be derived
from this.  Except one you mention: "counting reference", which I address
below.

> > 5. Way the singleton is destroyed

Why would anyone do anything other than destroy objects of static duration
(which is what a singleton is) in the reverse order of their construction?

> > 6. How to manage destruction [of] several coworking singletons

If A depends on B for construction, and B depends on A for destruction, I
consider that a design error.

> > 7. Synchronization policy: how and what to synchronize

I follow the simple policy of making the singleton construction thread-safe.
Singleton access synchronization is left to the user.

> > 8. Number of times singleton could be instantiated

I see here a second type of singleton -- one that has a counted reference
(from point 4) and could be re-created as necessary.  I think this could be
a separate singleton template.

In conclusion, I don't think we need to support policies that are:
  1) Easily done by the user (e.g., "&singleton<T>::instance()" instead of
defining a policy for the return type)
  2) Not useful (e.g., whether the underlying object is a static local in
some function or a static class member)

Policies are good, but don't abstract where abstraction isn't necessary. :)

        -Steve