Geometry Boost List: Re: [geometry] Run-Time specified geometries

Subject: Re: [geometry] Run-Time specified geometries
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2013-10-25 12:53:22

Hi Samuel,

To give it a shot I try to add variant support to "distance" taking
> "correct" as an example. Binary operation are more challenging since
> support for combinations (variant, variant), (non-variant, variant),
> (variant, non-variant) needs to be implemented.

You have an example of that in the equals algorithm.

> Moreover, if the variant
> has 2d and 3d points, the dimension of both geometry must be checked to
> be the same.

Basically I'm changing the was we handle algorithms to a multi stage
process. Where the only stage so far was dispatch, now we have:
- 1) variant resolution
- 2) default strategy resolution (after variant resolution because possibly
depends on the concrete geometry)
- 3) dispatch

After the variant resolution stage what you have on hand is guaranteed to
be a concrete geometry (or combination of concrete geometries). So you can
proceed to concept checks, default strategy resolution and so on. I had put
the concept check into a separate input_check stage and finally put it
directly in variant resolution, in the overload where resolution is done.
Not sure what will be the final choice but you get the point: anything that
depends on concrete geometries must be done after variant_resolution.

> That raise the question how to report runtime errors ?
> Exception ?
>

It's not a runtime error, as variant types are a compile time information.
Applying the multi stage resolution as described above will automatically
reject any variant that could possibly result in trying to compute the
distance between a 2D and a 3G geometry - e.g. passing instances of
variant<point<double, 2>, point<double, 3> > in parameters for distance
will result in a compile time error. One might argue it's too conservative,
as at run-time we won't necessarily end up asking for the fatal
combination. But I want to leverage variants type safety as much as
possible.

> Does that mean that we can dispatch incompatible variant to a runtime
> error using not_yet_implemented ? That would be brilliant !
>

Again, we go conservative here. Passing variants that could result in
computing a not yet implemented operation will result in a compile time
error.

Regards
Bruno