Re: [boost] Convert library to use Boost.Optional?

Subject: Re: [boost] Convert library to use Boost.Optional?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-05-22 03:12:09

2014-05-22 0:18 GMT+02:00 Vladimir Batov <Vladimir.Batov_at_[hidden]>:

> On 05/21/2014 07:45 PM, Andrzej Krzemienski wrote:
>
>> Hi Vladimir,
>> I have just made one observation regarding the return type. Now, that you
>> are using your custom boost::convert<TypeOut>::result, you can choose
>> what
>> exception type you want to throw from function value(). Your current
>> choice
>> is probably not the best one because you cannot distinguish with a type
>> alone between the failure to convert form string to T from any other std::
>> invalid_argument thrown in a big program. I recommend that you invent your
>> own type that can derive from
>> std::invalid_argument. This will work fine, but the problem will reappear
>> when you switch to boost::optional, because the latter is a general
>> purpose
>> library and it does not know the history behind the failure. It will throw
>> a generic "empty optional" error rather than something speciffic to
>> conversions. So, there is one disadvantage of using boost::optional. I do
>> not know how important you consider it to be. If it is a deal, and you do
>> not want to invent your own return type. Perhas you could use 'Expected':
>> http://www.hyc.io/boost/expected-proposal.pdf. It is proposed for
>> Standard
>> C++, And I think some work is being done to include it into Boost too. It
>> is similar to Boost.Optional, but conveys more information about the
>> reason
>> of failure. Might be worth considering.
>>
>>
> Andrzej,
>
> thank you for your input and suggestions. I glanced over (it was already
> quite late) the expected-proposal.pdf (can't say I understood everything)
> and I read/watched about Alexandrescu's Expected before. Initially
> deploying it seemed kinda tempting/interesting as indeed it's capable of
> conveying more information about failure reasons. Then I tried to see if I
> personally need/care for that additional information... so far it turns out
> I don't. I just do not have one single piece of code which would try to
> analyze the failure, correct something and then re-try conversion after it
> fails the first time around. More so, more elaborate reporting about
> conversion failure might be outright not possible. Say, I apply several
> formatting options to std::stringstream and conversion fails.
> std::stringstream does not tell me what exactly caused the failure, does
> it? More so, lexical_cast simply reports "conversion failed" and I do not
> remember ever reading any requests to extend that frugal reporting. So,
> there seems no need/appetite for such failure reporting. With that
> conclusion I feel sticking to/with std::tr2::optional or updated coming
> boost::optional. What do you think? Does it make sense?
>

Sure it does. I just realized that there is this trade-off to be made that
I was not aware earlier. It looks like you are already aware of it and have
made your call. That's fine.

Regards,
&rzej