Le 16/08/11 23:29, John Bytheway a écrit :
Hi all,
The review of Vicente Botet Escriba's Conversion library starts this Saturday August 20 and continues through August 29.
This library provides a general system for type-to-type conversion. As such, it can be thought of either as a substitute for overloading static_cast, or as an alternative to lexical_cast when the intermediate conversion to text is not wanted.
Your review and/or discussion would be greatly appreciated. As always, please post to the main Boost list if possible, or the boost-users list, or you can send your review directly to the Review Managers. The primary concern I always have with libraries such as this one is
On 16/08/11 15:59, Gordon Woodhull wrote: that they promote ODR violations. In particular, consider:
library A defines type TA
library B defines type TB
library C defines a conversion from TA to TB
library D defines a conversion from TA to TB
Now libraries C and D are incompatible; they cannot both be used in the same program without ODR violation. You are right and I have no solution to this big issue. I must add this to the documentation.
I think that the same case appears when library T defines a trait type tt that must be specialized by the user. library A defines type TA library C needs to specialize the type trait tt for TA library D needs to specialize the type trait tt for TA Now libraries C and D are incompatible for the same reason. An organization could choose to organize his libraries in a way that make possible to avoid the odr in an easy way. But it is not simple to formalize some guidelines that can be shared between different organizations. I don't know, even if the following is not a solution to the issue, maybe the library could suggest to the library author defining the conversion to add a static variable that could be used to detect the odr violations at link time. I don't remember who, suggested that library C should define classes C::TA and C::TB inheriting from TA and TB so one knows the other and conversion can be defined intrinsicaly to these specific classes. I have not explored the usage, advantages and liabilities of this approach.
This means, if I am writing a library, then I cannot safely define a conversion between types both of which are not in my library, because it would make my library incompatible with any other library that also defines such a conversion.
But, on the other hand, if one of the types *is* in my library, then I can probably make do with a conversion constructor or conversion operator (except perhaps if I want an explicit conversion operator and want to support compilers without those).
So, as I see it, conversions can only be defined in two situations:
- When writing non-library code (i.e. code that will not be combined with other code over which the author has no control).
Yes, here there is no problem as the author/organization can manage with which code is included in the executable.
- As a stop-gap substitute for explicit conversion operators. This was one of the initial motivation of the library.
Is it indeed intended only to allow conversions to be defined in these limited circumstances? If so, then the documentation should state that clearly. If not, how do you intend to avoid ODR violations?
You are completly right and during a good period I was tempted to withdraw the library submission. However,as you pointed out, there are some context in which the library is useful so I have persisted in the development. Thanks for raising (again) this big issue, which could be one of the reasons to reject the library. Best Vicente