Re: [boost] [review] string convert

Subject: Re: [boost] [review] string convert
From: Vladimir Batov (vbatov_at_[hidden])
Date: 2011-05-10 19:16:50

> Stewart, Robert <Robert.Stewart <at> sig.com> writes:
>> Vladimir Batov wrote:
> ...
>> 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.

Hmm, I forgot locales. I guess, quick spirit conversion does not support locales
(need to check). Then, every time we see locale_, format_ we switch to
stream-based. :-) I am somewhat uneasy about providing stream- and
non-stream-based conversions. I feel that an important value 'conversion library
is to decide *for* the user the quickest path. And different results are fine
IMO -- we specified locale_, format_, etc. after all... as long as it's
consistent. 

>> I am not sure converters are needed as we can feed
>> convert::to() to algorithms with 'bind' or 'lambda' .
> 
> That's a fair point...

More so, it'll see far less opposition. :-)

>> 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 myself actually much prefer 

T convert::to<T>(s, fallback)

>> (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).

I am certainly not a native speaker but "convert to" feels considerably more
natural than "convert as". 

T convert::to<T,S>(S, T& fallback, options)
bool convert::try_as<T,S>(S, T & _value, options)

I personally cannot see anything wrong with the above. The name difference seems
justified -- their behavior are quite different. So, the further they are apart
name-wise the better.

>> 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.

So, again, 

T convert::to<T,S>(S, T& fallback, options)
bool convert::try_as<T,S>(S, T & _value, options)

---------------

Something old. I am again having doubts if specializations will work well for

struct convert
{
    template<T, S, Enable> to(S const&, identity<T>::type const* =...);
};

I did look at Vicente's approach and it still (as the original 'convert') boils
down to the "tmpl<> class { tmpl<> func }" construct. The problem is that some
partial specializations are not such in the strict definition of the concept.
Namely, string-to-type conversion of the original 'convert' had to be done (IMO)
with 'enable_if' as it was not a partial specialization as such but rather a
particular *implementation* for a group of string-related classes. Then,
string-to-bool provided another implementation -- actual specialization --
template<> struct convert<bool>. I am under impression that such a scenario will
not work with the above (where T and S are together) as I suspect it won't work
with Vicente's library either. In other words, I am again having suspicions that
T and S need to be separated, i.e.

template<T>
struct convert
{
    template<S> from(S const&, ...);
};

I guess, I need to find time to actually try it again. 

Vicente, if you are reading this, do you actually have a working example of
semi-generic string-to-any-type "specialization" and, then string-to-bool
complete specialization?

V.

V.