On 3-5-2011 17:36, Stewart, Robert wrote:
Christopher Jefferson wrote:
[snip massive overquotation]
Out of interest, what would:
auto str = boost::convert<std::string>::from(123);
Do? If boost::convert stores by pointer/reference, it would be quite dangerous. str would be a boost::convert<std::string>::converter, not a std::string as one would probably expect.
Confirmed. This code: BOOST_AUTO(ia, convert<int>::from("123")); std::cout << typeid(ia).name() << std::endl; writes on MSVC: struct boost::convert<int,void>::converter<char const [4],void>
I think making libraries 'auto safe' is a good idea, I expect to see auto usage shoot up very quickly, and libraries should do their best to work well with auto. This may be one of the most compelling arguments against the current interface. Agreed.
This code: template <typename T> void dummy(T const& input) { std::cout << boost::is_arithmetic<T>::value << std::endl; } (....) dummy(convert<int>::from("123")); writes 0, so will be problematic in many generic functions, giving unexpected compilation errors where values are expected. We (in Boost.Geometry) did have in the past a distance result which was "convertable to a value". The reason was to save the sqrt, if possible (so comparing two distances without sqrt). However, this turned out to be quite problematic. As Eric Niebler said during BoostCon, something convertible to something is difficult to get right. We now return values everywhere (and there is a separate function comparable_distance) Finally: dummy(lexical_cast<int>("123")); writes 1 Regards, Barend