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