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

On 27.12.2015 00:19, Rob Stewart wrote:

On December 26, 2015 4:54:19 AM EST, Rainer Deyke 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@eldwood.com)