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
>>>> 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?
> 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; its 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:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk