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

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-11-13 15:22:10

Hi,

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:
 
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

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
3. How singleton is created
  a. using default constructor
  b. using non defaull constructor (how?)
  could be more
4. Way the singleton is accessed
  a. by pointer
  b. by const pointer
  c. by reference
  d. by const reference
  e. counting reference
5. Way the singleton is destroyed
  a. automatically after exit from main
  b. manually by user
  c automatically if not used
6. How to manage destruction several coworking singletons
  a. do not manage it
  b. make it in specified sequence
  c sinchronized
7. Syncronization policy: how and what to sinchronize
  a. do not synchronize at all
  many more alternatives
8. Number of times singleton could be instantiated
  a. One time   
  b. Many times - phoenix singleton

This is what I have right away. It seems that there are couple more 
dissisions to adopt. I do not have time now to work on it. Do you 
think it reasonable challenge?

Enjoy,

Gennadiy.

--- In boost_at_y..., Mattias Flodin <flodin_at_c...> wrote:
> Good day.
> 
> Having caught interest in boost, I've been reading the boost 
mailing lists
> for some time to get the general atmosphere of the discussions 
going on,
> and try to get a view of what is currently being worked on. So far, 
this
> has mostly concerned the thread and bind components.
> 
> Since I'm sure this is not the only work currently in progress, I 
don't
> find it too ignorant of me to ask if there is some kind of list 
being
> maintained of the elements that are currently pending for addition,
> or what items that have already been brought up for discussions but 
deemed
> uninteresting for boost.
> 
> The reason I ask is that I have, in a rather short time, been able 
to
> write down a surprising number of things that could be of interest 
to the
> library. Just as one might find certain designs strange at first 
sight
> (but then realize why it is so after reading the design rationale), 
I find
> it strange that some of these things seem to not yet have caught the
> interest of boosters.
> 
> So, after having made this request for a "work in progress" /
> "intentionally left out components" list, I hope you will forgive 
me if I
> now bring up a question that has already been discussed (or is even
> pending addition to the libraries):
> 
> How about a singleton class for boost? This is one of the most 
simple
> design patters, and can rather easily be implemented using 
templates. Just
> as the smart pointer, there may be a need for different variants, to
> handle the lifetime of the singleton in different ways.
> 
> I propose, to begin with, a singleton with no inherent 
instantiation,
> because it allows the most general handling of lifetime (the user
> instantiates it himself - but is not allowed to make two 
instantiations).
> There would be two functions: one to get a reference to the object, 
and
> the other to obtain a pointer to the same object. The former would 
throw
> an exception or fail an assertion if the singleton has not yet been
> instantiated, whereas the latter would simply return a null pointer.
> 
> To give you a more in-depth view of what I'm looking for, some code 
that
> I've been using follows; the implementation may of course need some 
work.
> Also see
> http://lib.stat.cmu.edu/~lamj/sigs/c++-
report/cppr9606.c.vlissides.html
> for some more discussion on the subject. If there is interest in 
this
> component, I will try to research it a little more and write up a 
more
> complete submission (with some initial documentation etc).
> 
> If you are not interested in the code you may stop reading here.
> 
> template <typename T>
> class singleton {
> public:
>     singleton()
>     {
>         assert(instance_==0);
> 
>         char* p=reinterpret_cast<char*>(this);
>         p-=(int)(singleton*)(T*)(1) - 1;
>         instance_=reinterpret_cast<T*>(p);
>     }
> 
>     static T& get()
>     {
>         assert(instance_!=0);
>         return *instance_;
>     }
> 
>     static T* getptr()
>     {
>         return instance_;
>     }
> 
> private:
>     static T* instance_;
> };
> 
> Regards,
>   Mattias
> 
> --
> Mattias Flodin <flodin_at_c...>   "A good thing about C++ is that only
> Room D418                           friends can access your private 
parts"
> Department of Computing Science
> Umeå University
> S-901 87 Umeå, Sweden
> Note: Any opinions expressed in this mail are personal, and do not
> necessarily reflect an official standpoint of Umeå University.