"Rozental, Gennadiy" <[EMAIL PROTECTED]> 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 boost::detail... > >> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost