-----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#docu... 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-----