Subject: Re: [boost] Boost.Conversion review
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-08-16 19:43:58
Le 16/08/11 23:29, John Bytheway a écrit :
> On 16/08/11 15:59, Gordon Woodhull wrote:
>> 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
> 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