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

Subject: Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.
From: Rainer Deyke (rainerd_at_[hidden])
Date: 2015-12-28 07:46:48

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).

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.

-- 
Rainer Deyke (rainerd_at_[hidden])