Boost logo

Boost :

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':
>> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at