Boost logo

Boost :

Subject: Re: [boost] [review] string convert
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2011-05-04 10:39:01

On May 4, 2011, at 9:57 AM, Matt Chambers wrote:
> I definitely could do without the tags to pick an overload. I'd much rather have the try_ prefix. So:
> int i = convert_cast<int>(s); // default behavior: might throw
> int i = convert_cast<int>(s, 17); // won't throw; can't tell if conversion successful; but how often do people actually care about that if they're providing a fallback value? it's still very practical and useful!
> optional<int> i = try_convert_cast<int>(s); // won't throw; specialized version of optional is not necessary since there's no fallback value

Yep, not bad.

> convert<int>::result i = try_convert_cast<int>(s, 17); // won't throw; specialized version of optional is necessary to detect failure

No, no special optional thing is needed. Please reread my 8:35am reply to Vladimir.

Sorry, it's a pair<bool, int>. Why do people hate pair? There's a boolean and a value, why is that not a pair? The returned value is not optional in this case.

> // I'd get rid of these:
> //int i = convert_cast<int>(s, 17, throw_even_though_i_specified_a_failback_); // what's the purpose of this overload?

This is the nondefaultable case where you still want it to throw.

> //optional<int> i = try_convert_cast<int>(s, 17); // this doesn't allow checking for failure, so there's not much point

Again, it's for nondefaultable types. You need to supply a value, but you wouldn't actually use it if conversion failed.

> //pair<bool,int> i = convert_cast<int>(s, 17, fallback_and_report_success_); // it's burning my eyes

Hahaha. Again, this is replaced by your try_convert_cast<int>(s, 17) and you could call it something else but it's really a pair.

So you get rid of two tags by adding one new function name. Sounds good to me.

On May 4, 2011, at 9:57 AM, Matt Chambers wrote:
>>> Finding the right prefix for "_cast" will be a challenge.
>> Sigh, another naming debate. (Naming is important but so difficult!) It does seem like the direction that *_cast<>() is clearer to people than convert<>()
>> I also like as<>() :-) but somehow I don't think that'll generate consensus.
> The first overload is a drop-in replacement for lexical_cast as far as I'm concerned (even with additional arguments for locale and manipulators). If it can pass all the lexical_cast tests, what's the harm?

I don't see any harm. Lexical Cast just needs a new maintainer who's willing to implement this stuff, against the intentions of the original author. IMO things do change.


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