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

From: peter.nordlund_at_[hidden]
Date: 2001-12-04 18:14:26

Hi Gennadiy, Mattias and others,

I have tried to address some of Gennadiy's suggestions.
The ones I think that I have solved, I have mentioned 
in Gennadiy's text below.
I have uploaded a zip-file in the directory SingletonWithManager.

If someone is interested in my suggested solution I will put
more work into it.

Best regards,
Peter

--- In boost_at_y..., "Gennadiy E. Rozental" <rogeeff_at_m...> wrote:
> 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

1. a,b

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

2. a,b,d

> 3. How singleton is created
>   a. using default constructor
>   b. using non defaull constructor (how?)
>   could be more

3. a

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

4. c,d

> 5. Way the singleton is destroyed
>   a. automatically after exit from main
>   b. manually by user
>   c automatically if not used

5. a,b

> 6. How to manage destruction several coworking singletons
>   a. do not manage it
>   b. make it in specified sequence
>   c sinchronized

6. a,b

> 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

8. a,b

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