Boost logo

Boost :

Subject: Re: [boost] [review] string convert
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2011-05-03 12:41:27


Stewart, Robert wrote:
> Jeff Flinn wrote:
>> Stewart, Robert wrote:
>>> Gordon Woodhull wrote:
>
> [snip massively overquoted context]

sorry thought I snipped that stuff.

>>>>> convert<int>::result res = convert<int>::from("blah", -1);
>>>>> if (!res) message("conversion failed");
>>>>> int value = res.value(); // proceed with the fallback
>>>>> anyway.
>>>> It's just that the next line might read
>>>>
>>>> int res2 = convert<int>::from("blah");
>>>>
>>>> and throw, and there's no indication why one version throws
>>>> and the other does not.
>>> Of course there is. One was given a fallback value and the
>>> other wasn't.
>> dynamic_cast sets a precedent for how to handle throwing/non-
>> throw variations:
>>
>> dynamic_cast<X&>(y); // throws if cast fails
>>
>> X* x = dynamic_cast<X*>(y); // returns 0
>>
>>
>> So if boost::optional is the analog of pointer, and we go to
>> some xxx_cast naming convention we could have:
>>
>> // throws if fails
>> int i = xxx_cast<int>(s);
>>
>> // returns empty optional if cast fails
>> boost::optional<int> oi = xxx_cast<boost::optional<int>>(s);
>>
>> // never fails
>> int i = xxx_cast<int>(s, 123);
>>
>> This just reuses boost::optional rather than the (superfluous
>> to me) convert<T>::result type. I for one see no reason that
>> _cast need be limited to a single argument.
>
> I really dislike the repetition of "boost::optional<int>" in that. What about going a little farther in the dynamic_cast direction (actually, following the boost::get precedent):
>
> int const i(xxx_cast<int>(s)); // throws on failure
> boost::optional<int> const oi(xxx_cast<int>(&s));

My gut reaction is that it lacks symmetry.

As mentioned else-thread, doesn't C++ 0x's auto solve the repetition
entirely, while being explicit as to what's going on?

auto oi(xxx_cast<boost::optional<int>>(s));

> Whereas dynamic_cast requires casting from a pointer type to a pointer type, here the suggestion is that casting from a pointer type implies casting to an optional. Note that the cast is "xxx_cast<int>" in both cases; it’s the source argument's being a pointer or not that dictates the overload and, thus, the return type.
>
>> If others find multiple arguments too disgusting, perhaps
>> boost::make<int>(s, 123) is more palatable.
>
> That name could work, but does it allow for formatting? IOW, "convert," like "translate," leaves room to consider formatting, including locales. "Make" suggests something more fixed to me.

I personally don't have those reservations and the applicability of
Make. Even more concise with perhaps less preconceptions might be:

   as<int>(s, 123);

Jeff


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