Re: [boost] [review] string convert

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