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

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
implementation.

> 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
  a.reset();
}

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 {
public:
  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           -           http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor