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.