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

On Monday 03 November 2008 13:54 pm, Johan Råde 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.

> If I were to switch from signals to signals2 in the projejct I'm currently
> working on, some trackable declaration would have to be replaced by several
> track calls. That would add a lot of clutter and I feel the new mechanism
> is more error prone.

Wrt clutter and error-proneness, 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.