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://listarchives.boost.org/mailman/listinfo.cgi/boost-users
>