Barend Gehrels wrote:
This is not concept refinement, or it would be a complex system of tags multiple inherited by other ones. We limit our dispatch cases in a finetuned way, so no "concept refinement" but "meta-function finetuning"...
This is not so different from what I'm doing, except that my meta-function finetuning is applied through the mechanism of SFINAE rather than looking up tags to pass to dispatch functions. I call my meta-function finetuning concept refinement because I'm detailing the inheritance relationships that way. These meta-functions could be replaced with boost::is_base_of calls and inheritance of concepts, which might be more convenient in the long run, assuming the dependency doesn't cause us headaches. I'd like to point out that you don't need three functions foo(single, single) foo(single, multiple) (reversible) foo(multiple, multiple) You can't assume a multi-geometry is a vector specifically, so you need to use iterator (or range) semantics in your multi-geometry traits. You can always view a single geometry as an iterator range with &single, &single+1 and treat it as a multi-geometry and can implement the const multi-geometry traits for it in that way. You can thus reduce many of your remaining function calls. I use this trick to implement the single-multiple and multiple-single cases as the same function as the multiple-multiple. I typically have a single single function also (since it might be needed in the implementation of multiple, multiple after all. Luke