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

Subject: Re: [boost] Formal Review Request: Boost.String.Convert
From: Vladimir.Batov_at_[hidden]
Date: 2009-02-18 22:47:36

I understand we'll never manage to please everyone. Apologies. For now I 
am settling on the boost::convert interface as I very much agree with the 
arguments Robert's put forward for it and I feel there is the least 
disagreement around this interface. Surely boost::convert() has issues of 
its own. However, I feel the path 
(convert::to_string->convert::to->convert) how I myself arrived to this 
logical (IMHO) conclusion seemed reasonable. More so, despite its subtle 
(to some) directionality the interface has proven to work (as it is 
essentially the same interface as for lexical_cast). You cannot deny that 
I made considerable sacrifices (my pets "string" namespace and "to/from" 
are gone, something I was ready to die :-) for yesterday...). I am hoping 
the others could make some concessions as well and we would settle on 
boost::convert()... for now. If some other issues pop up that we missed so 
far, we'll revisit the issue.

It is because I would very much like to move forward and start looking at 
the functionality and implementation. Do you think it is possible or I am 
rushing things again?

I somewhat cleaned up the implementation (removed to/from, etc.). However, 
before going forward I'd like to discuss one important thing that's been 
bugging me since Scott brought it up. Namely, all conversions are now 
implemented as discriminated functions like

// string-to-type conversion
template<class TypeOut, class StringIn>
typename boost::enable_if_c<
    !is_string<TypeOut>::value && is_string<StringIn>::value,
    detail::from_string<StringIn, TypeOut>
>::type
convert(StringIn const& from_str, TypeOut const& default_value =TypeOut())
{
    return detail::from_string<StringIn, TypeOut>(from_str, 
default_value);
}

However, Scott mentioned that and I feel that might be cleaner if we could 
implement it as 

namespace boost {

template<class TypeOut, class TypeIn, class Enable =void> class convert;

}

Then for every conversion we'll be able to encapsulate *complete* 
implementation in the respective specialization class. Like for 
string-to-type

template<
        class TypeOut, 
        class StringIn,
        typename boost::enable_if_c<
                !is_string<TypeOut>::value && is_string<StringIn>::value,
                void>::type>
class convert
{
        convert(StringIn const& from_str, TypeOut const& default_value 
=TypeOut());
};

The reason I like it is that it eliminates other support/intermediate 
classes (like something used-to-called boost::string::value<...> and 
detail::from_string) and we can do 

int i = convert(str, -1); // Nothing changed. a 'convert' instance created 
on the stack and converted to 'int'.
convert<int, string> checked(str, -1); // named 'convert' is created.
convert<int, string> checked = convert(str, -1); // the same but some 
might like this syntax better.
if (checked.good()) success // we can check the success as ussed to with 
boost::string::value

It feels that approach gives us considerably more room for expansion as 
some special conversions will be able to have methods only specific to 
that particular conversion.

For this approach to work with algorithms we'll need 

class convert
{
        static TypeOut apply(TypeIn const&);
};

and then

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

Thanks,
Vladimir.