Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.

Subject: Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-12-28 09:54:23

On December 28, 2015 7:46:48 AM EST, Rainer Deyke <rainerd_at_[hidden]> wrote:
> On 27.12.2015 00:19, Rob Stewart wrote:
> > On December 26, 2015 4:54:19 AM EST, Rainer Deyke
> > <rainerd_at_[hidden]> wrote:
> >> 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.
> 
> On a technical level, the only way either library can provide such a
> specialization is by either including a header from the other library
> (which counts as a dependency in my book) or by writing its own
> forward
> declaration of the types used in the other library (which counts as a
> dependency on the /implementation/ of the other library in my book).

Each can provide an extra header that has the interdependencies. That doesn't mean the libraries have any other dependencies.

> On a more philosophical level, neither library should provide
> specialize
> any Boost.QVM templates for types from another library unless one of
> the
> following is true:
> - The library in question requires such specializations as part of its
> internal workings, i.e. there is a strong, one-way dependency from the
> library in question to the other library.
>   - The whole point of the library in question is to provide such
> specializations.
> In the former case, there are IMO sufficient protections against ODR
> violations.  In the latter case, there is no point in using more than
> one such library in any given program.

I disagree with your assertion that those are the only valid reasons. Each may specialize the trait to specify their own type as the result when the two interact. Any user that combines code that triggers the inclusion of both sets of specializations would lead to an ODR violation, and there would be no clue that it has occurred. That is the danger inherent in such a customization point.

___
Rob

(Sent from my portable computation engine)