On 4/13/2012 7:23 AM, Michel Morin wrote:
Daniel Walker wrote:
It would be interesting to see how many Boost libraries actually require N3256.
Nathan Ridge and I made some efforts to test compatibility with decltype-based result_of. All the incompatibilities we found were just introduced by the incorrect use of result_of. They were not related to N3276.
IIRC, Pointer Container, Fusion and Spirit were fixed, but Phoenix is still in the fixing process.
Do you know if those fixes have made it to the release branch yet?
It wouldn't be hard to run the entire test suite using the decltype-based boost::result_of. We just need a volunteer to run the experiment. :-) Michel?
It's pretty easy for me to report the results of testing with decltype-based result_of, when the test runs successfully. But, when the test fails, it is not a trivial task for me to check whether the failure is actually caused by decltype-based result_of :/ (Of course, if someone requests testing with decltype-based result_of for a specific library, I'll try to test it :-) )
I think modifying Jamfile to add the test with decltype-based result_of is a reasonable approach to the regression tests.
One way to check this on a one-time basis would be to run the tests once with tr1 result_of, and again with decltype-based result_of, and to check for new failures. We can make such a test an ongoing thing by taking one test runner and having it run in both configs. If that's the only difference between the test runs, the problem is easy to identify. Only one test runner would have to do this. I'm not sure if the test infrastructure has a way of globally adding a <define>BOOST_RESULT_OF_USE_TR1 to all targets. Does it? -- Eric Niebler BoostPro Computing http://www.boostpro.com