Le Wed, 25 Jul 2012 11:39:05 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> a écrit :
On Wed, Jul 25, 2012 at 7:55 AM, Julien Jorge <julien.jorge@gamned.org>wrote:
For the case of the double type, I guess I can find a workaround by providing a specialized implementation for Boost.Geometry and keeping the previous implementation for the general case.
Oh I see, the Point concept can work with types like double if it is wrapped as bg::model::point<double, 1>. Not sure it's the best strategy to deal with it but that's a possibility you could use for any type that is not accepted by boost geometry, as a last resort conversion. I guess you'll have to try different strategies see what's efficient.
I finally managed to make the tweeners to work with both Boost.Geometry and double by selecting the implementation using bg::tag<P>::type. If the tag is not void, the implementation uses the algorithms of Boost.Geometry. Otherwise it falls back to the default computation using the default operators. However, if the user of the library has a custom coordinate type that cannot be adapted to bg::point and for which the arithmetic operators are not defined, then he won't be able to use the single_tweener as is. There is still the solution for him to use a tweener_group on each dimension of the type but maybe the library should provide a way to pass the operators to the tweeners (through some kind of point_traits?). Julien Jorge