Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-05-10 08:29:32

Vladimir Batov wrote:
> > Stewart, Robert <Robert.Stewart <at> sig.com> writes:
> >
> >> T convert::to<T>(S, boost::parameter-list);
> >
> > Vicente has been discussing the issue of stream-based
> > conversions WRT manipulators.  In lexical_cast-style
> > conversions, there's an insertion followed by an
> > extraction.  Are manipulators needed for both directions?
> > If so, the interface must allow for them using,
> > say, "in" and "out" keywords instead of "format_."
>
> There has been no need for that. The original 'convert' was
> applying manipulators in both directions. The in/out
> direction is defined by the string-to-type or type-to-string
> specialization.

That came up in my reply to Matt.  I think Matt and I agree with you.  Unless Vicente can find a use case, the manipulators-apply-to-the-string view is sufficient.

> > to<T>() seems a very nice name for stream-based conversions.
>
> I am not sure why that distinction has to be made. Now that
> converters are gone

That isn't clear yet.

> and all parameters are provided in one call, the implementer
> knows what conversion is needed. That is, if there are no
> 'format_' parameters specified, then, say, spirit-based quick
> conversion is applied. As soon as I see 'format_', then I fall
> back to stream-based. So, all we seem to need is convert::to.

Stream-based and non-stream-based conversions can easily provide different results, without using manipulators to influence things, if for no reason other than the global locale's influence.  It seems useful to be able to explicitly invoke a stream-based conversion without specifying manipulators.  Whether the stream-based conversion API uses a different set of names or is in a distinct namespace is a separate matter.

> > This leaves the fate of the converter function objects
> > unclear.  That functionality seems too useful to drop.
>
> I am not sure converters are needed as we can feed
> convert::to() to algorithms with 'bind' or 'lambda' .

That's a fair point.  However, I think there's still value in the converters because while the function templates take advantage of template parameter deduction, a class template (converter) can use partial specialization.  Partial specialization will probably be beneficial for customizations.  If you accept that, then making the converters function objects is a small step.

> > To summarize, here's the complete API as I see it now:
> >
> > 1. convert::default_value<T> customization point
> >   * Default value, if needed, when not otherwise supplied
>
> I expressed my opposition to default_value. It was not needed
> for the original 'convert', i.e. we can get away without it.
> Asking the user to supply this arbitrary functionality is
> bothersome and will be mis-used/abused.

The interfaces that obviated default_value were questioned, however.  Using default_value makes various interfaces simpler.  One isn't required to use it, however.  There are API choices that don't rely on it.

> > 3. T convert::convert_cast<T,S>(S)
> >   * Throws on failure unless T is convert::result<T'>
> >   * Uses convert::converter<T,S> to do conversion
>
> T convert::to<T>(s) seems to work as well. Less API to
> remember.

I like to<T>(S) very much, but it doesn't lend itself as well to all of the API variations.  I know you don't care to have the try_convert_to(S, T &) interface, but others find value in it, so accounting for its name is necessary.

> > 4. T convert::convert_cast<T,S>(S, T _fallback)
> >   * Returns _fallback on failure unless T is
> convert::result<T'>
> >   * Uses convert::converter<T,S> to do conversion
>
> T convert::to<T>(s, (fallback_ = ...)) seems to work as well.
> Less API to remember.

Writing "(fallback_ = _fallback)" seems harder to remember than that there's an overload taking a second argument.

> (I user convert::to instead of convert::as. Not sure if
> convert::as was intentional or accidental).

It was intentional because it allowed for #9.

as<int>(s) reads about as well as to<int>(s).

> > 9. bool convert::try_as<T,S>(S, T & _value, options)
> >   * Returns false and leaves _value unchanged on failure
> >   * Uses convert::stream_converter<T,S> to do conversion
>
> That's a lot. I'd seem to manage with just convert::to. :-) ...
> even though it did not make it onto the list.

If we could agree on "as" rather than "to," it might be workable because "try_as" works reasonably well for the interface you dislike.

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.