Subject: Re: [boost] [type_erasure] ODR violation promotion
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-09-09 16:06:19
Le 09/09/11 21:46, Gordon Woodhull a écrit :
> On Sep 9, 2011, at 3:26 PM, Vicente J. Botet Escriba wrote:
>> Le 09/09/11 20:44, Steven Watanabe a écrit :
>>>> Before the Boost.Conversion review someone signaled that the
>>>> Boost.Conversion review was promoting ODR violations as two libraries
>>>> could specialize a conversion for types S and T and make them
>>>> incompatible for an end user as the ODR is violated.
>>>> I think that your library suffer from the same issue, when two libraries
>>>> need to specialize a concept provided by the library for a 3rd part
>>>> concrete class using the proposed concept map mechanism. Do you agree?
>>>> If not, how do the library avoids this kind of issue?
>>> I have no intention of trying to deal with it.
>>> As far as I'm concerned it's the responsibility
>>> of whoever defines the specializations. I'm
>>> not going to worry about it at all until I
>>> hear reports of it causing real problems, as
>>> opposed to being a purely theoretical concern.
>> IIUC you response, you agree that your library has the same problem.
> Or, it is not a real problem.
> Or, as Roman Perepelitsa suggested, it is a more serious problem if you are defining customizations on two types, because then it is unclear which library has responsibility for defining the customizations.
Or, the library can not be used with 3rd party types by other libraries
without promoting ODR violations ;-)
Note that 3rd party libraries could not be aware of the existence of
Boost.TypeErasure or any other library that could define concepts that
can be mapped and can not define themsenves the specialization for them.
Or, may be I'm wrong and there is a solution to this problem?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk