
Geometry : 
Subject: Re: [geometry] Report not yet implemented feature at runtime
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 20150516 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 compiletime.
> > 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 aspectoriented way:
arity, which input params are variantable, what's the default result type,
default strategy, which inputparams are commutative, and so on. With this
+ the actual pertype implementation, you would have nothing else to write
to spawn an algorithm. All the boiler plate stuff that currently happens in
the multistage 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
Geometry list run by mateusz at loskot.net