Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Matt Chambers (matt.chambers42_at_[hidden])
Date: 2011-05-06 01:03:19

On 5/5/2011 6:58 PM, Vladimir Batov wrote:
>> Matthew Chambers<matt.chambers42<at>  gmail.com>  writes:
>>
>> Did you ever use boost.convert on a non-defaultable type? I've never needed
>> that.
> [...snip...]
> An enumerator as simple as
>
> enum hamlet_problem { to_be, not_to_be };
>
> has no default. I am not sure if extending the above to
>
> enum hamlet_problem { to_be, not_to_be, i_dont_know };
>
> will be helpful for poor Hamlet. From the design perspectives adding elements
> not relevant to the domain (i_dont_know) is pollution.
I agree that in some cases there is no sensible default/fallback value. In those 
cases, the only concern is whether the conversion succeeded, right?
So optional<T> will work fine for that case, but it would have to be renamed so 
it doesn't conflict with the simple, throwing convert_cast<T>(s):
optional<hamlet_problem> t = optional_convert_to<hamlet_problem>(s);
This can be in addition to try_convert_to, which would still be useful when both 
the conversion success and the final value (fallback or not) are wanted.

In an earlier message you wrote this about the try_convert_to method:
> #5 IMO can. It deploys the Pascal-style parameter passing and modifications. I
> remember reading Stroustrup (I think) long time ago advising against passing
> non-const references and I personally agree. That's due to potential confusion
> and wrong expectations. I am not aware of any function in std and boost doing
> that. Introducing such a precedent might be a hard-sell.
If you want a precedent for taking output as a by-reference parameter: 
boost::algorithm::split. Further, I'm not sure how output references could be 
considered more confusing than the output iterators that are ubiquitous in std 
algorithms.

Outside the enum case, have you considered that your use of convert on so many 
object types mixes lexical conversion and serialization (admittedly related 
concepts)?
In my experience, the former uses a simple, concise interface intended for value 
types while the latter uses a verbose interface supporting both object types and 
value types.
What's the rationale for a lexical conversion library to support serialization?

-Matt