Jeroen Habraken wrote:
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.
You are right and the same applies to any type-to-type conversion. And maybe this is the MAJOR flaw of Boost.Conversion: to think that we can define extrinsically THE conversion between two types. Every body admit that if a class T defines a constructor from a std::string THE conversion from std::string to T is the one defined by this constructor. Boost.Conversion pretend to provide a specialization point to state what is THE conversion from one type to another extrinsically. Of course, the fact that this is done outside both classes allows to have two different points of view that will be ambiguous if the two view are visible from the same compilation unit or will violate the ODR if both views are present on the same program. Note that this issue is not only limited to Boost.Conversion but to any function that could be overloaded by the user or any template class that can be specialized by the user. Two different parts of a program could make the same overloading or the same specialization. This doesn't implies that we should avoid overloading or specializations. It seems clear to me that if we don't have a consensus on the default type-to-type conversion extrinsically Boost.Conversion mustn't not provide it, neither the user. Does it means that Boost.Conversion has no sens? I don't know. Coming back to the string to int conversion, if we can not have a default string-to-type or type-to-string, Boost.Conversion must remove these specializations. Thanks Jeroen and Harmut for raising this issue before the review, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Conversion-pre-review-request-tp365... Sent from the Boost - Dev mailing list archive at Nabble.com.