Re: [boost] [review] string convert

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

Hi Jeff!

On May 4, 2011, at 11:00 AM, Jeff Flinn wrote:

> Gordon Woodhull wrote:
>> On May 4, 2011, at 10:33 AM, Stewart, Robert wrote:
>>> The only other one I haven't commented on is the pair<bool,int> version.  It shouldn't require a second argument.  All of the variations that take a single argument should have a version that takes a second in case there's no default construction or zero-initialization possible.  That aside, the pair version leads to much less readable code, not least because the semantics of pair<int,bool> are less obvious than those of optional<int>.  
>> We're going in circles because it's hard to keep all the use-cases in one's head at one time.
>> Something is needed here, when you want to use the fallback but you also want to know if conversion succeeded.  See that snippet from Vladimir that I just quoted again in my reply to Matt.
> 
> I'm having a hard time envisioning why you would ever care if conversion failed if you are specifying a default. Is that in the snippet you refer to? Can you show it in this context to avoid confusion?

Two use cases: 

1. nondefaultable, no sentinel.  So you're supplying a default value which is not a fallback. Return should be optional<T>.

2. 
On May 3, 2011, at 8:36 AM, Vladimir Batov wrote:
> For better or worse my usual processing flow of configuration parameters:
> 
> // Try reading a configuration parameter.
> convert<int>::result i = convert<int>::from(s, 17);
> // Log error if parameter was bad.
> if(!i) message ("parameter ignored. default used");
> // Proceed with the default.
> return i.value();  // returns 17 (!)

I argue this is a pair.  Or call it something else which is still a pair.  ;-)

> 
> In any case you would then use the version returning optional and the client code could then do what it needs to do.

Yes, that's what I said, but Rob shot that down with the nondefaultable stuff.  (And apparently forgot, understandably.)

And I can see the value of Vladimir's case, where he wants to supply the fallback along with the conversion, and then see if the fallback got used.

Getting loopy,
Gordon