Re: [boost] A design for geometric objects

Subject: Re: [boost] A design for geometric objects
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2008-11-15 18:45:43

Simonson, Lucanus J wrote:
> Thank you, Mathias and Bruno for your helpful and frank feedback on my design.

I was afraid I had been a little harsh.
Good to know you were not hurt by my comments ;).

> The runtime case was for selecting algorithms based on whether the data stored by the object is simpler than what the object is capable of storing, which can only be known at runtime.

So you have both runtime and compile-time detections on what some 
geometric object is.
How do you factor the code?

Ideally, it would be nice to be able to fuse the compile-time and the 
runtime mechanisms.
A is_rectangle meta-function is not much different than a is_rectangle 
function, after all. Maybe it is possible to generate the runtime 
function from the compile-time function.

Also, you could try to do your forwarding automatically
Instead of

template <typename output_container_type, typename polygon_data_type>
void polygon_concept::get_trapezoids(output_container_type& output, 
const polygon_data_type& polygon) {
        CONCEPT_ID id = concept_downcast(polygon);
        if(id == POLYGON_90_CONCEPT) {
                polygon_90_concept::get_trapezoids(output, polygon); return;
        } else if(id == POLYGON_45_CONCEPT) {
                polygon_45_concept::get_trapezoids(output, polygon); return;
        }
        //implementation of arbitrary angle slicing of polygon into trapezoids
}

You could write

template <typename output_container_type, typename polygon_data_type>
void polygon_concept::get_trapezoids(output_container_type& output, 
const polygon_data_type& polygon)
{
     //implementation of arbitrary angle slicing of polygon into trapezoids
}

template <typename output_container_type, typename polygon_data_type>
void polygon_concept::get_trapezoids(output_container_type& output, 
const polygon_data_type& polygon)
{
     visit<polygon_90_concept, polygon_45_concept>(
         polygon,
         bind(get_trapezoids, output, _1),
         bind(get_trapezoids_polygon, output, _1)
     );
        
}

the visit function would attempt to downcast the first argument to all 
types in the list and then call the second argument with the downcasted 
object. If no downcast is possible, it calls the third argument.
That's a possible and simplistic design, there are certainly better ones.
The main issue is that it doesn't allow multiple dispatch.