> 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. > 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? Gennadiy _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
