Re: [boost] [review] Conversion - About specialization, overloading and ODR

Subject: Re: [boost] [review] Conversion - About specialization, overloading and ODR
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-08-31 12:26:32

Le 31/08/11 08:44, Roman Perepelitsa a écrit :
> 2011/8/31 Vicente J. Botet Escriba<vicente.botet_at_[hidden]>
>
>> Hi,
>>
>> during the Boost.Conversion review and pre-review it has been argued that
>> as the user must provide specializations of the conversion function for
>> other UDT's, it could  promotr ODR violations as two independent libraries
>>   can provide the same specialization making them incompatible for an end
>> user.
>>
>> This issue is present for any library for which the user could provide an
>> overload or could specialize a class. The standard library protects itself
>> from this issue saying that is undefined behavior any specializations of
>> standard classes (except maybe numeric_traits that has a single parameters
>> and it is intendeed to be specialized by the library providing the UDT).
>>
>> My question is: Should Boost (all the Boost libraries) document explicitly
>> that any class specialization or overload of free fuctions could result in
>> undefined behavior? Is this already implicitly acknowledged?
>
> This problem arises only with functions taking arguments of different UDT
> types.
>
> It's not a problem with operator+ or swap: they logically form the UDT's
> interface and hence are "owned" by the author of the UDT. It's also not a
> problem with something like bool parse(const string&, udt*), even though it
> has two different UDTs as parameters.
They form part of the UDT if they are provided by the same library, but 
not when they are provided by a 3rd lib.
> It is, however, a problem with conversion functions because it's not clear
> who "owns" them. Can I, as author of class foo, provide conversion from footo
> bar? What about the reverse?
>
If you are the author of class foo and you know class bar it seems 
natural that if there is a possible conversion this conversion be 
defined inside the class foo. The reverse works in the same way.

Best,
Vicente