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

Subject: Re: [boost] [review] Conversion - About specialization, overloading and ODR
From: Roman Perepelitsa (roman.perepelitsa_at_[hidden])
Date: 2011-08-31 12:47:26

2011/8/31 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>

> Le 31/08/11 08:44, Roman Perepelitsa a écrit :
>
>  2011/8/31 Vicente J. Botet Escriba<vicente.botet_at_wanadoo.**fr<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.

The rule I follow is that operator+(x, x) can be provided only by the author
of x. If xdoesn't have such operator, third parties can't add one. The same
applies to swap and other functions that are expected to be found by ADL and
form the type's interface.

>
>  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.

This makes the problem you are having unique to Boost.Conversion. Although
it is indeed acknowledged that providing two function specializations or
overloads with the same template arguments is a violation of ODR, only
Boost.Conversion invites its users to violate the rule. Things like swap
don't suffer from it.

>
>
> Best,
> Vicente
>
> ______________________________**_________________
> Unsubscribe & other changes: http://lists.boost.org/**
> mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
>