Subject: Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.
From: Rob Stewart (rob.stewart_at_[hidden])
Date: 2015-12-29 04:50:55
On December 29, 2015 4:19:47 AM EST, Rainer Deyke <rainerd_at_[hidden]> wrote:
> On 28.12.2015 15:54, Rob Stewart wrote:
> > Each can provide an extra header that has the interdependencies.
> > 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
> > Each may specialize the trait to specify their own type as the
> > 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
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.
(Sent from my portable computation engine)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk