[boost] Fw: [Boost-users] [signals2][review] The review of the signals2library (formerly thread_safe_signals) begins today, Nov 1st

Subject: [boost] Fw: [Boost-users] [signals2][review] The review of the signals2library (formerly thread_safe_signals) begins today, Nov 1st
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-11-12 05:37:09

forwarding to boost_at_[hidden]

----- Original Message ----- 
From: "Frank Mori Hess" <frank.hess_at_[hidden]>
To: <boost-users_at_[hidden]>
Sent: Monday, November 10, 2008 4:25 PM
Subject: Re: [Boost-users] [signals2][review] The review of the 
signals2library (formerly thread_safe_signals) begins today, Nov 1st

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 10 November 2008 05:30 am, Fabio Fracassi wrote:
>> * Automatic connection management:
>> This is great, even if it wasn't required for thread safety reasons, I
>> prefer using shared_ptr based connection tracking over boost::trackable,
>> since it enables me to track (and thus safely use) 3d party classes.
>
> One issue that has occurred to me with the shared_ptr use, is it requires 
> the
> use of boost::shared_ptr.  So, if someone's program is instead always 
> using
> std::shared_ptr for example, that could be a bit of an annoyance.  One
> solution would be to make it support anything that provides the
> shared_ptr/weak_ptr interface by making slotN::track() a template and 
> doing
> some type erasure inside the library.  Unfortunately, neither the 
> shared_ptr
> or weak_ptr interface provides a typedef for it's associated
> weak_ptr/shared_ptr type, and I would need to get both the weak_ptr and
> shared_ptr type from the single argument passed to slotN::track().  So, 
> I'd
> have to add some template traits classes that could determine if a class 
> is a
> shared_ptr or weak_ptr, and the type of its associated weak_ptr or
> shared_ptr.  I could provide specializations of the traits classes for the
> shared_ptr/weak_ptr implementations I know about (boost, std, tr1, etc),
> otherwise the user would have to provide a specialization.
>
> The other option would be to add yet another template parameter to the 
> signal
> class for the shared_ptr type, but it has too many parameters already.
>
>> I haven't done a comparison, but the Docu seems to be mostly the same as
>> the original signals. Thus for the usecases that are documentated there
>> its high quality, but I miss the same for the new features:
>>
>> * I miss tutorial quality examples for some of the new features:
>>    ** Howto use boost::threads with signals2
>>    ** Howto use postconstructors/predestructors (and what for?)
>>    ** An example using signal::extended_slot_type
>
> Yes, it seems clear I'm not going to get away with the minimal porting job 
> I
> did on the Boost.Signals documentation.  Speaking of the postconstructor
> stuff, I'm not entirely happy with the deconstruct_ptr interface.  Maybe 
> I'd
> like it better if it looked more like make_shared/allocate_shared and had 
> a
> helper for declaring it as a friend, as has been recently proposed on
> boost-devel for make/allocate_shared.
>
>> * The class reference pages (e.g.
>> doc/html/boost/signals2/connection.html) are missing from the TOC
>
> That's just how boostbook does it.  The TOC links to the header synopsis, 
> and
> the class names in the header synopsis link to the class reference pages. 
> I
> do remember having a little trouble navigating through it myself initially
> though.
>
>> * Do the portable syntax examples need to be supported (... so
>> prominently)? Maybe they could be moved to an appendix?
>
> I agree they don't, although most of the other additions to the docs 
> people
> have been asking for would seem to take precedence.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJGFJu5vihyNWuA4URAsUpAJ0TVggC9K9Zy76p1AxtfnxA1VomsgCeL1Z8
> TrXkG8+WbKkBDS7SiUF+0+Y=
> =zb8l
> -----END PGP SIGNATURE-----
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>