Re: [boost] Boost.Convert. Take 2.

Subject: Re: [boost] Boost.Convert. Take 2.
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-02-21 05:36:48

On February 21, 2014 3:25:23 AM EST, Vladimir Batov <vb.mail.247_at_[hidden]> wrote:
>Rob Stewart <robertstewart <at> comcast.net> writes:
>> On February 20, 2014 5:48:18 PM EST, Vladimir Batov <Vladimir.Batov
><at>
>constrainttec.com> wrote:
>> >On 02/21/2014 02:47 AM, Andrzej Krzemienski wrote:
>> >>
>> >> Regarding "Type Requirements" section in documentation:
>> >> TypeOut needs to be
>> >>
>> >> *Copy Constructible.*
>> >> Is it not enough to require that TypeOut be *MoveConstructible*?
>> > ...
>> >Still I suspect some interfaces require to be Copy Constrictible.
>For 
>> >example,
>> >
>> >template<typename TypeOut>
>> >struct boost::convert<TypeOut>::result
>> >{
>> >     ...
>> >     template<typename FallbackType>
>> >     out_type value_or(FallbackType const& fallback) const
>> >     {
>> >         return good_ ? value_ : fallback;
>> >     }
>> >};
>> 
>> This would address your concern:
>> 
>> if (good_)
>> {
>>    return std::move(value_);
>> }
>> else
>> {
>>    return fallback; 
>> }
>> 
>> However,  for non-movable types,  the fallback is to copy anyway,
>> so both should be moved. 
>
>The problem is, I think, with
>
>>    return std::move(value_);
>
>because it destroys "value_" which in general terms I do not think we
>can
>do. For example, (I'll use tr1::optional instead of
>convert<T>::result):
>
>tr1::optional<std::string> res = convert<std::string>::from(12345,
>cnv);
>std::string str = res.value_or("bummer");
>
>... if value_or() moves/destroys the string inside "res",
>... then "res" is not usable from here downwards
>... it's a problem, isn't it?

I should have been clearer. If the argument is movable, move it. If not, don't. That means overloading based upon rvalue references vs. lvalue vs. small, by-value args. I was just showing the one case. 

___
Rob

(Sent from my portable computation engine)