Hi, On 9 July 2011 16:20, Vicente Botet <vicente.botet@wanadoo.fr> wrote:
Jeroen Habraken wrote:
Hi,
Colour me curious, but what's the advantage of wrapping boost.coerce in boost.conversion? We're trying to create a sensible API for boost.coerce (which, as we've seen, is quite a challenge for a conversion library) and I personally do not see the benefit of it being wrapped with a different API in a different library.
The scope of Boost.Conversion is not to define specific conversions but allow to put all the basic type-to-type conversion using a generic interface. If Boost.Coerce provide an string to type efficient conversion Boost.Conversion can provide a specialization for string to types conversion that will delegate to Boost.Coerce. At the end std::string is a type as others.
Boost.Conversion provides currently and optional (specific file) a specialization for string-to-type and type-to-string that uses lexical_cast. It will try to make this specialization available only if the used expression is valid, but I have no taken the needed time yet.
Best, Vicente
It is important to note there is no generic way of implementing type-to-string and string-to-type which is the reason that boost::lexical_cast and boost::coerce can co-exist. Whilst there is definitely an overlap in the problems both libraries solve the approach is significantly different. If one must support locale than lexical_cast is the way to go, if one prefers runtime speed than coerce is the way to go. Since these libraries obviously aren't drop-in replacements of each other the user must make an informed decision and pick one based on his/her requirements. This also means, in my opinion anyways, that boost.conversion can't generically wrap both in a meaningful way since they operate differently and one can't switch between them without consequences. Jeroen