Boost logo

Boost :

Subject: Re: [boost] [review] Convert library
From: Vladimir Batov (vb.mail.247_at_[hidden])
Date: 2014-05-26 05:08:19


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);

as Alex suggested converter has op()(TypeIn const&, optional<T>&) signature.
So, the above calls

converter(from, res)

i.e. simply passes "res" straight to the converter. Inside the converter you
fill that "res" with the result (potentially with move semantics). I do not
see any extra-copying anywhere. More so, convert() is seemingly easily wiped
out/inlined altogether. What am I missing?

Jeroen, do you think you might take the "convert" port_review branch and add
your "coerce" test there? A couple of hours of community work? :-)

--
View this message in context: http://boost.2283326.n4.nabble.com/review-Convert-library-tp4662821p4662887.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk