Re: [boost] singleton_ptr

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-07-17 17:55:49

On Sun, 17 Jul 2005 18:01:38 -0400, Jason Hise wrote
> Jeff Garland wrote:
>
> The old version was perfectly usable, but by redesigning after 
> everything I learned the first time I have been able to make 
> significant organizational improvements, simplifications, and 
> interface enhancements.  I didn't start over just because of 
> threading concerns.

Ok, good.
 
> Create, destroy, and access to member functions through smart 
> pointers are locked, so a destroy followed by a recreate should not 
> invalidate the pointer in another thread (based on their location in

Ok, but the other client has a pointer to the old singleton, no?
 
> my code, destroy and create would be completed as one atomic step).  
> When used by the other thread, the pointer would automatically 
> forward to whichever instance exists.

Smart pointer isn't going to do this, unless you have some special singleton
pointer that somehow knows to reset itself or always calls 'instance' behind
the scenes...

> It could be useful to destroy and recreate a singleton for any 
> number of reasons, but for one example consider a graphics engine. 
>  If the full screen application is minimized and then expanded again 
> all graphics card resources would need to be reacquired.  This is 
> could be most naturally handled by destroying and recreating a 
> singleton in charge of the display.

Ok, but I have to say that singleton seems like a terrible approach your
particular use case.  The 'Graphics Engine' singleton should just release and
reaquire the resources without direct client access or recreating of the
singleton itself.  By far and away the most usual case for singletons is
create once (often before main) and destruct last (often in atexit).  

> I tend to agree.  Although at first I thought that the destruction 
> of an already destroyed instance was similar semantically to a 
> double delete 
> (and hence should throw an exception) I now no longer think that it 
> makes sense to regard double destruction as a programming error, 
> especially in multi-threaded contexts.

Yep.
 
> Thanks for the comments, hopefully the first version of the new 
> singleton library will be ready for release before this summer is out.

Look forward to it.

Jeff