Geometry Boost List: Re: [geometry] Report not yet implemented feature at runtime

Subject: Re: [geometry] Report not yet implemented feature at runtime
From: Samuel Debionne (samuel.debionne_at_[hidden])
Date: 2015-03-18 04:58:53

Hi,

> Boost.Variant is a high level type erasure library, just like
> Boost.Any. Just because we currently support variants doesn't mean
> we shouldn't support Any (or a more specialized equivalent) or any
> other form of type erasure applied to our library.

I agree the two are not exclusives and even serve different purposes.
Menelaos has reminded me something you wrote about variant that I would
like to quote here :

> I think Bruno in a private email exchange explained it in a very
> nice way: variants are not geometries. Support for variants in
> Boost.Geometry does not mean that variants are understood as
> geometries, but rather than Boost.Geometry is variant-aware (i.e.,
> it can handle variants).

Variants are not geometries and are "resolved" very early in the
algorithm stages so that the penalty of using type erasure remains low.
In the other hand, any_point would be a geometry and a direct
replacement of an other model. But it would not be able to hold several
types that implement different concepts (while variant can).

> I've been thinking for very long about using algorithm tags to
> identify our algorithms and give them specific characteristics which
> could then be used in many ways. What you are proposing is one of
> the possible usages. So yes, the approach could make sense.

Good to hear that you had a similar idea. What other applications of
algorithm tags do you have in mind ?

In the prototype I mention in the origin post, there is more that just
deciding if a not yet implemented (nyi) algorithm should static assert
or throw. It also requires that every single nyi feature to compile,
that is even for inapplicable type combinations. For that, a fake
implementation should be provided for algorithms but also for
intermediate results (see not_implemented_result_handler). While my
solution works it requires to inspect and fix every algorithm/strategy
implementation. Do you have any idea how to solve this problem with a
less intrusive solution ?

Moreover, I think I was quite lucky to pick the within algorithm as an
example, intersection would have been much more challenging since the
result type depends on the input types. It would be nice if such
algorithm expose a meta function to compute the result type...

Finally, here is a blog post from the MySQL team that covers part of
this topic.

http://mysqlserverteam.com/author/david/

> Note that for some binary GIS functions, some type combinations are
> inapplicable or not supported, and we return false or NULL
> respectively for such cases.
>
> Undefined/inapplicable type combinations for each function are:
>
> overlap: any combination of two argument types of different dimensions
> crosses: any of the two argument types is point or multipoint
> touches: the 1st argument is polygon or multipolygon, AND/OR the 2nd >
argument is point or multipoint

Unfortunately, it does not elaborate on the solution they use to
"filter" these type combinations.

Regards,
Samuel