Vladimir Batov wrote on Saturday, May 24, 2014 9:40 PM
Habraken wrote The most trivial use of boost::convert, and boost::lexical_cast and boost::coerce simply don't compare in my opinion.
boost::cstringstream_converter cnv; int i = boost::convert <int>::from("23", cnv).value();
versus
int i = boost::lexical_cast<int>("23"); int j = boost::coerce::as<int>("23");
Here we go again... :-) lexical_cast will be haunting me to my grave. :-)
For starters, please stop using that silly lexical_cast deployment example as our benchmark. Such deployment does not exist. >lexical_cast cannot possibly be deployed like that in any real application. The correct and responsible deployment is
int i = -1; int j = -1;
try { i = boost::lexical_cast<int>(str); } catch (...) {} try { j = boost::lexical_cast<int>(str); } catch (...) {}
which is not exactly the two-liner that you sited! Compared to that the "convert" usage is
boost::cstringstream_converter cnv; int i = boost::convert<int>(str, cnv).value_or(-1); int j = boost::convert<int>(str, cnv).value_or(-1);
does look simple and intuitive enough IMO, configurable and potentially more efficient. (In the post_review branch the >convert::from API has been retired).
I guess I'm silly, but such deployment does exist in my code base, to good effect. Convert "something" to "something else". If it doesn't work, throw an exception. That's a typical C++ idiom. Any implementation that requires some cryptic object-creation-before-I-call-a-function doesn't make sense to me. Your example adds default-value functionality, which is usually (in my use cases) inappropriate.
When the convert library makes it into boost I'd want to mentally deprecate lexical_cast as a library I should use, and always use convert instead. This means convert should have a default converter, which may well be backed by lexical_cast with an interface such as:
int i = boost::convert<int>::from("23").value();
This still doesn't completely satisfy me as I'd like to write
int i = boost::convert<int>::from("23");
Again, I can't possibly stress more that the (deceivingly simple) usage examples you insist on do not exist in real >applications -- they are functionally-incomplete (as they do not handle all possible use-cases). Still, with the post_review branch one can responsibly(!) write
int i = boost::convert<int>(str, cnv).value_or(-1);
I can't possibly stress more that those cases do exist. I know that in my application, I almost never know some default value_or, so if the conversion doesn't work, I *want* an exception. Forcing the programmer to decide appropriate default values for every conversion isn't silly- I don't know, I just want a valid conversion or an exception. At any rate, I largely agree with Jeroen's points, and I find the Convert interface excessively complex. Specifically, if I have to create a conversion object that I then immediately pass as an argument to a conversion function, that seems excessively complex to me. Erik ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.