2014-05-26 11:08 GMT+02:00 Vladimir Batov
Jeroen Habraken wrote
On 26 May 2014 10:12, Vladimir Batov <
vb.mail.247@
> wrote:
... I actually ran tests with lexical_cast and others: naked lex_cast vs. convert+lex_cast. No performance degradation. I mention it in the docs.
This will unfortunately not be the case if Hartmut is right, and Andrzej just confirmed he might be. The optional-based interface may actually introduce more in overhead than boost::coerce requires for the conversion.
As said this needs to be backed by numbers, which is difficult without the std::tr2::optional in boost, but this may turn out to be a problem to me. Later versions of GCC are actually capable of optimizing
boost::coerce::as <int> ("23");
to the number 23 at compile time. I'd be a shame to have this obstructed by an optional.
I do not see Andrzej confirming anything. He indeed asked a question... which a far from a confirmation of any sort. The way I see it
user-level optional<T> res = convert<T>(from, cnv);
the standard optimization/elision mechanism is to pass "res" to convert(). So, it becomes
convert(optional<T>& res, from, cnv);
I claim (without evidence in form of benchmarks) that returning optional<T> by value should not be slower than passing it as an input argument. Most compilers elide the moves/copies today, don't they? I would recommend making measurements before applying this optimization.