Re: [boost] [signals2][review] The review of the signals2 library is scheduled to end on Monday, November 10th

Subject: Re: [boost] [signals2][review] The review of the signals2 library is scheduled to end on Monday, November 10th
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-11-10 11:01:32

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 10 November 2008 05:09 am, Franz Alt wrote:
> If the user wants to use a different mutex (e.g. 'dummy_mutex') it must
> take the default values for all the other template arguments. This could
> lead to something like this:
>
> typedef signals2::signal
>   <
> 	void (bool),
> 	signals2::optional_last_value<typename boost::function_traits<void
> (bool)>::result_type>, 

I'm just nitpicking here, but a user would just write:

signals2::optional_last_value<void>

for the Combiner,

> int, 
> 	std::less<int>,
> 	function<void (bool)>,
> 	typename signals2::detail::extended_signature<function_traits<void
> (bool)>::arity, void (bool)>::function_type, signals2::dummy_mutex

and a user would write

function<void (const signals2::connection &, bool)>

for the ExtendedSlotFunction.

>
>   > signal_t;
>
> This isn't really user friendly. 

That's true.  The Mutex parameter got put at the end because it was a new 
addition and putting it at the end was more backwards compatible.  The 
relevant suggestions on dealing with this have been: removing some of the 
parameters like SlotFunction and ExtendedSlotFunction (my suggestion), and 
using Boost.Parameter (as Vincent Botet suggested).

One problem with Boost.Parameter is how to document it in the Signals2 
reference.  See the "best practices: documentation" section of the 
Boost.Parameter docs:

http://www.boost.org/doc/libs/1_37_0/libs/parameter/doc/html/index.html#documentation

Another possibility might be to remove Mutex as a template parameter from the 
signal class and instead pass the mutex type to the signal constructor, so 
only the constructor would be templated on the Mutex type.

> The former version of boost.signals needs 0.78s for the test, the new
> version needs 3.20s. This supports my feeling that there could be done more
> optimication at boost.signals2.

Yes, the tracking overhead speed can be optimized further.  To be clear 
though, the boost::trackable connection management in Boost.Signals can have 
zero overhead on invocation, while the shared_ptr/weak_ptr will always have 
some overhead due to locking the tracked weak_ptr into shared_ptr before 
running the slots.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJGFrc5vihyNWuA4URAqAeAJ0enqxTJm7ZzNkcPTbM3ia8mytRPgCgq406
SslpCWPZJ9ZzvAlDZkt86i0=
=M4Wy
-----END PGP SIGNATURE-----