On 01/07/2015 11:40 AM, Peter Dimov wrote:
Michael Caisse wrote:
This worries me. I have had mixed results with type traits specifically and the behaviour of the Boost flavour versus the std flavour from various vendors. I don't recall the specifics right now except to recall that the std::is_pod in MSVC produced different results than gcc and Boost.
Our practice has generally been to not use the std version of something if it fails our tests, although there's always the possibility that your code happens to not be covered by our test suite.
Yes, I understand that. We discussed this practice in May when the steering committee met and so I was bringing it up again partially as a reminder. I find the practice very surprising as a user and would prefer that it was controlled by a preprocessor flag and not done automagically. We might be all excited about std versions of things but at the end of the day 1. we don't control them, and 2. they are not the Boost implementation and may have different behaviour (performance, results, side affects ...). The subject came up as we were discussing this general practice and what to do with C++11 std libraries that overlap Boost. I'm somewhat opposed to the TR1 type thing we did where we automagically swap out implementations with the vendor version. I'm not opposed to using the vendor version but I think we need to provide control so that when something breaks for the user they can move back to the Boost version. michael -- Michael Caisse ciere consulting ciere.com