Boost logo

Boost :

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>
convert(StringIn const& from_str, TypeOut const& default_value =TypeOut())
    return detail::from_string<StringIn, TypeOut>(from_str,

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

        class TypeOut,
        class StringIn,
        typename boost::enable_if_c<
                !is_string<TypeOut>::value && is_string<StringIn>::value,
class convert
        convert(StringIn const& from_str, TypeOut const& default_value

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

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

        convert<string, int>::apply);


Boost list run by bdawes at, gregod at, cpdaniel at, john at