Subject: Re: [boost] [review] string convert
From: Matthew Chambers (matt.chambers42_at_[hidden])
Date: 2011-05-04 15:20:48
On 5/4/2011 2:01 PM, Stewart, Robert wrote:
>>> convert_cast(s, 17) has the same problem and breaks with the
>>> new-style cast pattern.
>> What is the breaking aspect?
> New-style casts are of the form xxx_cast<T>(S). Thus, that has to be convert_cast<int>(s, 17) to fit.
This is a special case of the discussion below.
>>> The target type should be required in all cases, I suspect,
>>> to make things clearer:
>>> try_convert_to<int>(s, i) clearly indicates that int is the
>>> target type.
>> Yes, but thanks to type inference users are free to write
>> try_convert_to(s, i) instead and that's even worse than
>> try_convert(s, i). :)
> You can make the second argument non-deducible thus requiring the target type.
I didn't know that was possible. How? If the target is non-deducible then I agree the _to suffix for
optional_convert and try_convert is good.
Back to something you said earlier:
>>> If others agree, I could also go with Vincente's version of
>>> try_convert. It doesn't bother me that passing in the variable
>>> by reference makes it a two-liner, since the expression itself
>>> can go inside the if statement and it implicitly supports
>>> non-default-constructable types.
> It is certainly non-surprising.
> Using Vicente's default_value customization point still makes convert_cast<optional<T>> a viable candidate:
> auto const c(convert_cast<optional<int>>(s));
> if (c)
> // use c.get()
What about UDT specializations for casting to and from optional<T> (i.e. string<->optional<int>
where 'n/a' could be the unset string)?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk