On December 29, 2015 4:19:47 AM EST, Rainer Deyke
On 28.12.2015 15:54, Rob Stewart wrote:
Each can provide an extra header that has the interdependencies. That doesn't mean the libraries have any other dependencies.
So, don't include that header.
Of course that's the way to preclude the problem, but it isn't always so easy.
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.
This is not a valid reason, precisely because it can lead to an ODR violation.
Are you being purposely obtuse? If two separate libraries use one each of the specializations, and some new application has need to use both libraries, there will be an ODR violation, most likely without the knowledge of the programmer combining the two libraries. The "validity" of the reason stems from the need to use the two libraries, not from their specializing, or not, the QVM traits. ___ Rob (Sent from my portable computation engine)