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 02:44:19

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.

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?

Roman Perepelitsa.