[review] Conversion - About specialization, overloading and ODR
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? Best, Vicente
2011/8/31 Vicente J. Botet Escriba <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. 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.
Le 31/08/11 08:44, Roman Perepelitsa a écrit :
2011/8/31 Vicente J. Botet Escriba<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. 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
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>
On Aug 31, 2011, at 12:47 PM, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
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.
If you were defining operator+(X,Y) you'd have the same problem. Any customization point involving two or more types seems to suffer this problem. Cheers Gordon
2011/8/31 Gordon Woodhull <gordon@woodhull.com>
On Aug 31, 2011, at 12:47 PM, Roman Perepelitsa < roman.perepelitsa@gmail.com> wrote:
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.
If you were defining operator+(X,Y) you'd have the same problem. Any customization point involving two or more types seems to suffer this problem.
All I'm saying is that customization points requiring two UDTs are bad. I would say that a library that promotes them should't be part of boost. Roman Perepelitsa.
On Aug 31, 2011, at 1:21 PM, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
All I'm saying is that customization points requiring two UDTs are bad.
Oh, I see. Wow, is that always true?
I would say that a library that promotes them should't be part of boost.
Opinion noted.
Le 31/08/11 19:21, Roman Perepelitsa a écrit :
2011/8/31 Gordon Woodhull<gordon@woodhull.com>
On Aug 31, 2011, at 12:47 PM, Roman Perepelitsa< roman.perepelitsa@gmail.com> wrote:
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. If you were defining operator+(X,Y) you'd have the same problem. Any customization point involving two or more types seems to suffer this problem.
All I'm saying is that customization points requiring two UDTs are bad. I would say that a library that promotes them should't be part of boost.
You are surely right as Boost.Conversion need to be especialized for two types, adn the library has no mean to prevent the user that a bad usage can fall on ODR violations. I started this post as I think the same problem could appear for other Boost libraries with customization points independly of the number of types. I think that libraries with customization points with one parameter need to add a warning on the documentation telling the user that the specific customization of a UDT must be done by the same library that provides the UDT and that no other library can provide a customization point for a type provided by a 3rd library. Best, Vicente
participants (3)
-
Gordon Woodhull -
Roman Perepelitsa -
Vicente J. Botet Escriba