[type_erasure] ODR violation promotion
Hi Steven, I'm interested in your TypeErasure library. Where can I find the on going version? The example for concept map seams not complete, as the specialization for less_than_comparable<std::type_info> is not used in any type erasure type. Could you complete it? 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? Best, Vicente
AMDG On 09/09/2011 11:23 AM, Vicente J. Botet Escriba wrote:
I'm interested in your TypeErasure library. Where can I find the on going version?
I've been keeping the repository on my own machine. I'll push it in to the sandbox eventually.
The example for concept map seams not complete, as the specialization for less_than_comparable<std::type_info> is not used in any type erasure type. Could you complete it?
What more do you want to see? Something like this: { any<less_than_comparable<>, _self&> t1(typeid(int)); any<less_than_comparable<>, _self&> t2(typeid(double)); bool b = t1 < t2; // b == typeid(int).before(typeid(double)) } I had assumed that this would be obvious. I'd rather not clutter the examples too much. The important part is the specialization.
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. In Christ, Steven Watanabe
Le 09/09/11 20:44, Steven Watanabe a écrit :
AMDG
On 09/09/2011 11:23 AM, Vicente J. Botet Escriba wrote:
The example for concept map seams not complete, as the specialization for less_than_comparable<std::type_info> is not used in any type erasure type. Could you complete it?
What more do you want to see?
Something like this:
{ any<less_than_comparable<>, _self&> t1(typeid(int)); any<less_than_comparable<>, _self&> t2(typeid(double)); bool b = t1< t2; // b == typeid(int).before(typeid(double)) }
I had assumed that this would be obvious. I'd rather not clutter the examples too much. The important part is the specialization. I would prefer an example that uses the specialization, but of course It is up to you to include whatever you want.
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. Thanks, Vicnte
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. Cheers, Gordon
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? Best, Vicente Vicente
I don't think it's fair to single out TypeErasure here. Customization through template specializations or overloads is everywhere. On Sep 9, 2011, at 4:06 PM, Vicente J. Botet Escriba wrote:
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?
The complete program has to have some consistent policy so that conflicts are impossible. I don't think the fact that you could run into ODR problems with a library means that the library "promotes" ODR violations, and actually I think this may be an overstatement for Conversion as well. IMO it is easier to imagine a design policy where concept maps are defined consistently than one for libraries defining conversions. I think this is because a concept map is more likely to have only one reasonable definition than a conversion. I do not see any hard-and-fast rule (yet?) It does look like the problem was acknowledged with the dearly departed concepts, and the proposed solution was to define concept maps in namespaces: see "scoped concept maps". IIUC I don't see how anything like that technique could apply here and now. Cheers, Gordon
I don't think it's fair to single out TypeErasure here. That was no my intention. It is just that with Boost.Generic, these were
Le 10/09/11 04:19, Gordon Woodhull a écrit : the two last libraries I was reading on that have an explicit convept map.
Customization through template specializations or overloads is everywhere.
Do you have other examples of Boost.Libraries that have the same issue?
On Sep 9, 2011, at 4:06 PM, Vicente J. Botet Escriba wrote:
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?
The complete program has to have some consistent policy so that conflicts are impossible. I don't think the fact that you could run into ODR problems with a library means that the library "promotes" ODR violations, and actually I think this may be an overstatement for Conversion as well.
You are right, as the library works well in most of the cases. I was trying to delimit the application scope of the library. Maybe it will be enoug to add to the documentation that the library can not be used with 3rd party types that need a concept map.
IMO it is easier to imagine a design policy where concept maps are defined consistently than one for libraries defining conversions.
I think this is because a concept map is more likely to have only one reasonable definition than a conversion. I do not see any hard-and-fast rule (yet?) You are right, the definition should be unique, but nothing ensures that
You are right, as the conversion unicity on the concept map unicity or something like that. (Recall that I constrained the scope of the Boost.Conversion library to types that model the same underlying type concept). the concept map defined by two independent teams will be the same, isn't it?
It does look like the problem was acknowledged with the dearly departed concepts, and the proposed solution was to define concept maps in namespaces: see "scoped concept maps". IIUC I don't see how anything like that technique could apply here and now.
I'm interesteed in knowing how scoped concept maps solve the issue. Have you a pointer? Best, Vicente
On Sep 10, 2011, at 1:11 AM, Vicente J. Botet Escriba wrote:
I'm interesteed in knowing how scoped concept maps solve the issue. Have you a pointer?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2098.pdf
Le 10/09/11 07:18, Gordon Woodhull a écrit :
On Sep 10, 2011, at 1:11 AM, Vicente J. Botet Escriba wrote:
I'm interesteed in knowing how scoped concept maps solve the issue. Have you a pointer? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2098.pdf
Thanks, really interesting. As I understand the scoped concept proposal will allow several concept maps for the same concrete class. The map is closer to an adaptor that is choosen transparently for the user depending on the namespace context usage. Simulating this behavior in C++11 should not be transparent. Do you know if this was retained in the standard just before the Concept proposal was removed? Best, Vicente
On Sep 10, 2011, at 6:53 AM, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
Do you know if this was retained in the standard just before the Concept proposal was removed?
Yes. http://conceptgcc.wordpress.com/2007/04/18/concepts-go-to-core/
participants (3)
-
Gordon Woodhull -
Steven Watanabe -
Vicente J. Botet Escriba