Subject: Re: [geometry] Report not yet implemented feature at runtime
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2015-05-16 03:32:54
Hi Samuel,
Sorry for the big delay in answering this.
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).
>
Yep, I would agree with such a use of Boost.Variant to implement any_point,
and yes, unlike variants this one could be considered a geometry as the
underlying concept is known at compile-time.
> > 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 ?
>
Algorithms would declare their characteristics in an aspect-oriented way:
arity, which input params are variant-able, what's the default result type,
default strategy, which input-params are commutative, and so on. With this
+ the actual per-type implementation, you would have nothing else to write
to spawn an algorithm. All the boiler plate stuff that currently happens in
the multi-stage dispatching (variant handling, commutation, handling, etc.)
would be generated for you by the Boost.Geometry framework (which of course
would be the tricky part to write).
> 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 ?
>
This is why we first need to have algorithms declare themselves in the way
I'm describing above. I see this as the building block to many things.
> 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...
>
It's always difficult to choose whether to start from the easiest or the
hardest. For variant I chose the former approaches as I was fairly
confident there would be no showstopper with the more sophisticated algos.
For this one I think whatever solution you come up with should be validated
with the most complicated algo before the first commit, just to check
feasibility.
Regards
Bruno