Boost logo

Boost :

From: Rainer Deyke (root_at_[hidden])
Date: 2001-11-13 18:26:42

----- Original Message -----
From: "Gennadiy E. Rozental" <rogeeff_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, November 13, 2001 1:22 PM
Subject: [boost] Re: Work in progress list? And how about a singleton?

> I am also looking in this direction for some time now. Here what I
> think we need to make a really reusable singleton. The singleton
> design should be able to adopt following design desision made by user:

This looks like a backwards approach: you don't start with a problem that
you're trying to solve, but an abstraction which may or may not prove useful
in solving real problems. When I need global state that is sensitive to
creation order in my program, I tend to do something like this:

std::vector<std::string>& get_strings()
  static std::vector<std::string> strings;
  return strings;

The problem is thus solved in six lines without the need for a singleton
class and its single instance. I think there is a real danger that an
overly abstract design makes it harder to configure and use your singleton
class than to write a specific singleton from scratch.

> 1. Way the singleton is instantiated. Possible variations:
> a. Static pointer as class member
> b. Static pointer as local variable in some method
> c. static variable as class member
> d. Static variable as local variable in some method
> e. Static variable in implementation file
> g. Variable in thread-specific storage
> and couple more

Excepting the last one, which solves an entirely different problem, what
difference does it make? The user cares about functionality, not

> 2. When singleton is created:
> a. automatically before main
> b. automatically in static memory at the point of first access
> d. automatically in dynamic memory at the point of first access
> c. mannually by user
> and couple more

Several issues here.

 - Sometimes a global resource has a specific lifetime. This is easily
modeled through a pointer.

boost::scoped_ptr<A> a = 0;

int main()
  a.reset(new A);
  // something else

Sometimes the lifetime of such a global resource is tied to some other
object, in which something like this would work:

class A;
A *a = 0;
class A {
  A() { assert(!a); a = this; }
  ~A() { a = 0; }

int main()
  A shared_a;
  // something else

 - Sometimes a global resource does not have a specific lifetime, it just
needs to be there when I need it. In this case any creation time other than
first point of access doesn't really make sense. I also don't see any
significant commonality between this type of shared resource and the other
type, so I would not attempt a single class that handles both.

 - If the object is created before 'main', then any exceptions thrown during
construction cannot be caught.

> 4. Way the singleton is accessed
> a. by pointer
> b. by const pointer
> c. by reference
> d. by const reference

By pointer if the pointer could be a null pointer to indicate the object is
not yet created or already destroyed. By reference otherwise.

> e. counting reference

I assume this is in support of 5c below?

> 5. Way the singleton is destroyed
> a. automatically after exit from main

This is the only one that makes sense for global resources that are created
on point of first access.

> b. manually by user

This is the only one that makes sense if the user manually creates it.

> c automatically if not used

This seems to be another different type of global resource, not necessarily
related to the others.

> 6. How to manage destruction several coworking singletons

Inverse order of construction.

> 8. Number of times singleton could be instantiated
> a. One time

This is automatically the case if it is created on point of first access and
remains in existence until exit from main.

> b. Many times - phoenix singleton

This is automatically the case if it's lifetime is controlled by the user.

Rainer Deyke (root_at_[hidden])
Shareware computer games           - 
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor

Boost list run by bdawes at, gregod at, cpdaniel at, john at