Johan Råde | 4 Nov 20:41
Picon
Picon

Re: [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st

Frank Mori Hess wrote:
>> What is the rationale for ditching boost::trackable?
> 
> It's not thread-safe.  I'm not opposed to including an implementation of it 
> for backwards compatibility though.  It does seem like a less painful porting 
> path for single-threaded code should be provided.

I think that would be a good idea. It will make porting a lot smoother.
However, since it is not thread safe, it should probably not be enabled by default,
but only when the user defines some macro.

> one idea (I haven't decided if it's a good 
> one or not yet) would be to add a signals2::trackable which is based on 
> enable_shared_from_this.  It could use visit_each like Boost.Signals does, 
> and then use enable_shared_from_this on any signals2::trackable objects it 
> finds to get a shared_ptr for tracking.  Or it could throw an exception if it 
> finds a signals2::trackable object not owned by a shared_ptr.

That is a very interesting idea.

--Johan Råde

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Gmane