Subject: Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-12-29 05:16:31
Le 27/12/2015 17:00, Emil Dotchevski a écrit :
> On Sat, Dec 26, 2015 at 5:19 PM, Rob Stewart <rob.stewart_at_[hidden]>
>> On December 26, 2015 4:54:19 AM EST, Rainer Deyke <rainerd_at_[hidden]>
>>> On 25.12.2015 13:03, Rob Stewart wrote:
>>>> I think, rather than X and Y providing conflicting definitions, the
>>>> problem is that abc provides a specialization to allow
>>>> interoperability with def, and def does the same for abc. Using the
>>>> two libraries, in that case, always creates a conflict.
>>> This implies a circular dependency between abc and def. If those
>>> libraries are that tightly coupled, surely they can work out this
>>> conflict between themselves?
>> It implies no such thing. It implies that each library provider chose,
>> independently, to offer interoperability with the other using QVM.
> It isn't exactly interoperability. The specialization in question isn't
> needed to make library X and Y compatible with each other using QVM, that's
> automatic. It only specifies the return type of operator* when multiplying
> e.g. X::matrix by Y::matrix; and it is plain wrong for X or Y to specify
> that, because the user most likely wants to get a my_matrix instead.
You should document this fact on the documentation.
> That's of course in addition to the fact that a library can't be
> responsible for ODR violations introduced by the user.
Any library that allows the user to customize its behavior must define a
way that allows the user to avoid ODR violations, otherwise the use of
the library by 3pp libraries don't scale.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk