forwarding to boost@list.boost.org ----- Original Message ----- From: "Frank Mori Hess" <frank.hess@nist.gov> To: <boost-users@lists.boost.org> 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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users