Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Matt Chambers (matt.chambers42_at_[hidden])
Date: 2011-05-06 11:52:42

On 5/6/2011 5:45 AM, Vladimir Batov wrote:
> Again, my typical concern is twofold -- result of conversion and the return 
> value (converted or fallback). The following is my typical use-case (note the 
> second -- to_be -- parameter that you seemingly missed in your example)
>
> optional<hamlet_problem> t = optional_convert_to<hamlet_problem>(s, to_be);
>
> if (!t)
> {
>    message("Invalid input. Using fallback");
>    t = to_be;
> }
>
> [...different post...]
>
> // Constructed by whatever means available. Not the def. cntr
> direction fallback (direction::up);
> convert<direction>::result res = convert<direction>::from(str, fallback);
> direction reconstructed_from_str = res.value();
>
> For big classes with value-semantics it might be quite an overhead. However, 
> our classes are overwhelmingly pointer-semantics pimpl-based classes. That way 
> we essentially apply something that probably can be called in-place 
> re-initialization. For me it's somewhat over-engineered and we've been moving 
> towards "class::class(xml::element const&)" for unserialization. Still, all 
> the current features of 'convert' are needed. They will be (hopefully) used on 
> smaller scale though.
Your examples are hypocritical based on your earlier argument about there not 
being a meaningful default value for your non-defaultable types. We agreed there 
is no meaningful default for the "to_be or not_to_be" problem, so your usage 
here of defaulting it to to_be doesn't make sense. Especially when you proceed 
to use the return value that's invalid...

If a default value makes sense, then you use:
hamlet_problem t = to_be;
if (!try_convert_to<hamlet_problem>(s, t))
{
   message("Invalid input. Using fallback");
}

It's briefer than your version.

The same goes for your direction class. We really need more context to 
understand your use case and why either the optional<T> optional_convert_to 
(without a fallback/default provided, because the value isn't needed if it 
fails) or try_convert_to doesn't work for you. I know your argument about the 
output by reference, but that is merely an interface concern which other 
participants here haven't yet shared.

-Matt