Re: [boost] [review] Convert library

Subject: Re: [boost] [review] Convert library
From: Jeroen Habraken (vexocide_at_[hidden])
Date: 2014-05-26 05:23:25

On 26 May 2014 11:08, Vladimir Batov <vb.mail.247_at_[hidden]> wrote:

> Jeroen Habraken wrote
> > On 26 May 2014 10:12, Vladimir Batov &lt;
>
> > vb.mail.247@
>
> > &gt; 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? :-)
>

I may have time at the end of the week, but no promises unfortunately.

Jeroen