Gordon Woodhull wrote:
On Jul 9, 2011, at 11:39 AM, Vicente Botet wrote:
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.
Yes, this is a problem with all global customization points.
I would expect than any one developer would want to use either lexical_cast or coerce. However, does the ODR mean that the exact same conversions would have to be defined in a library and in any code that uses the library? That sounds tricky!
Just document it as a known limitation and reviewers can decide
Yes. we can not have two customizations that conflict within 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.
Right.
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,
IIUC it's providing the conversions and the user chooses them by #including the headers of interest.
neither the user.
? Really?
Well, we have two kind of users. Final users and library author users. The final users can choose to include the header of their interest as far as there is no conflict in the whole program, but library author users can use only consensual type-to-type conversions if they want its library to be reusable in a large context.
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.
Seems to me there are still defaults: decimal provided by either lexical_cast or coerce depending on user preferences. And the user has to be careful.
Or are you saying that since all libraries linked into a program must agree on which conversions to use, Conversion should only define ones that everyone agrees on? That sounds rather extreme. Why not just stipulate that the set must be the same throughout the program? Libraries would document or allow customization of which converters they use.
Yes, this is exactly the point. There couldn't be a conflict in the whole program. Library authors could document the conversions choices they have taken, but the use of a non-consensual conversion will make the library less usable. I don't think that Boost.Conversion can provide a string-to-type conversion that is configurable. It could provide one if there is a consensus of a default. We should see Boost.Conversion customization as if we were adding some methods to one of the classes. For the string to float conversions, it is as if we were adding explicit operator float() const; to the std::string class. Best, 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.