GTL compile time and concepts redesign

I have modified my example code to move the accessors out of the templated traits class and into a non-templated concept struct as Fernando suggested. I also added compile time accessors that are parameterized by enum values, which I decided would give me the benefits of type safety and readability I was getting with my isotropic types as runtime parameters, while allowing the much desired compile-time parameter for people who prefer it. The runtime accessors are still there and call the compile-time accessors by default. The user can specialize the accessors to adapt them to their type, but now it is significantly harder to do so, because previously the accessors were members of a template class, and it was the class that was specialized, allowing the functions to retain their template parameter list. Now I am unable to partially specialize the accessor functions, which means that I cannot make their arguments template parameters of the function (because the user can't be expected to specialize for every conceivable type.) The user also has to explicitly specialize each version of the compile-time accessor, such as: template <> inline rectangle_traits<LayoutObject>::interval_type rectangle_concept::get<HORIZONTAL>(const LayoutObject& rectangle) { return rectangle_traits<LayoutObject>::interval_type(rectangle.xl, rectangle.xh); } template <> inline rectangle_traits<LayoutObject>::interval_type rectangle_concept::get<VERTICAL>(const LayoutObject& rectangle) { return rectangle_traits<LayoutObject>::interval_type(rectangle.yl, rectangle.yh); } and can't do the following: template <orientation_2d_enum orient> inline rectangle_traits<LayoutObject>::interval_type rectangle_concept::get(const LayoutObject& rectangle) { if(orient == HORIZONTAL) return rectangle_traits<LayoutObject>::interval_type(rectangle.xl, rectangle.xh); return rectangle_traits<LayoutObject>::interval_type(rectangle.yl, rectangle.yh); } as might be their first inclination. I'm not sure to what extent that makes specializing the accessors harder. User feedback I get is that specialization (all kinds) is hard, and in practice I usually help them out by providing the specializations they need for the types they have to get them over that first hurdle and running with library. I feel that there is still some more progress to be made here, please have a look. Thanks, Luke
participants (1)
-
Simonson, Lucanus J