From: David Abrahams (dave_at_[hidden])
Date: 2003-02-14 18:27:27
"Rozental, Gennadiy" <gennadiy.rozental_at_[hidden]> writes:
>> If we are going to generalize this there should be a single
>> boost::function0<void> argument, and if you're going to go down this
>> path we should /definitely/ generalize it. Replicating this design
>> pattern in two separate libraries would be a big mistake.
> I could not afford boost::function dependency in so low level
> component as execution_monitor (or even unit_test_monitor). If we
> will be able to design it as pluggable extension to Boost.Test I
> would of course prefer the way you implemented it in Boost.Python
> with boost::function0<void> argument.
Well, there's no need to use boost::function0<void> I suppose, since
that's easily emulated with a smart pointer to an appropriate abstract
base class. Given a suitable templated invocation function I think
we could even get it to accept the same range of nullary function
objects that boost::function0<void> accepts, and there would never be
any need to use boost::ref on it for optimization purposes because of
the nature of the call.
Maybe I should do the factorization and put it in the sandbox or
>> optimization crop up). This is not an idiom that's been
>> well-exercised in compiler vendors' test suites, it seems.
> Still, what about conformance to standard?
What about it?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk