Re: [boost] Formal Review Request: Boost.Convert

Subject: Re: [boost] Formal Review Request: Boost.Convert
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-19 02:57:21

Correction. I meant to say the following

namespace boost
{
    template<class TypeIn, class TypeOut, class Enable =void> class convert;
}

// string-to-type specialization
template<class StringIn, class TypeOut>
class convert<
    StringIn,
    TypeOut,
    typename boost::enable_if_c<
        is_string<StringIn>::value && !is_string<TypeOut>::value,
        void>::type>
    >
{
    convert(StringIn const&, TypeOut const& =TypeOut());
    operator TypeOut const& () const {...}
    static TypeOut apply(StringIn const&) { ...}
};

int string_to_int = convert<string, int>(str, -1);
int string_to_int = convert<string, int>(str);
convert<string, int> string_to_int(str, -1);
convert<string, int> string_to_int = convert<string, int>(str, -1);

std::transform(
        integers.begin(),
        integer.end(),
        std::back_inserter(strings),
        convert<string, int>::apply);

As you can see there is *no* type-deducing. That is, with that approach 
we'll have to always indicate 'to' and 'from' types. That seems verbose... 
but might be a plus as it takes *any* ambiguity out.

That gives us a lot of freedom. Like

1.    using boost::convert;
2.    typedef boost::convert<string, int> StringToInt;
3.    optimization can be done on individual type-to-type or
category-to-category basis
4.    any specific exotic conversion can be added on when needed basis and
locally by the user.
5.    conversion-specific methods can be added to individual conversions or
constructors extended (as in one of Scott's examples:

struct convert<
    string,
    int,
    enable_if>
{
    convert(string, int)
    convert(string, int, rounding) // Added special constructor
}

V.