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

Subject: Re: [Boost-users] [signals2][review] The review of the signals2 library (formerly thread_safe_signals) begins today, Nov 1st
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-11-10 10:25:34

-----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-----