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