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

Subject: Re: [geometry] Run-Time specified geometries
From: Samuel Debionne (samuel.debionne_at_[hidden])
Date: 2014-04-30 10:39:20

Hello Adam,

> Hmm, maybe we could move MPL_ASSERT from the not_implemented<> members
> to some default implementations of not_implemented<>::apply(). The
> drawback is that it should be some number of those default apply()
> methods to handle all possible number of parameters. It should fail only
> when the user wanted to call the function but it would also be possible
> to check if the algorithm is implemented in compile-time without raising
> the alarm. Something like this:
> 
> template <typename ReturnType, ...>
> struct not_implemented
>     : nyi::not_implemented_tag
> {
>     template <typename P1>
>     static inline ReturnType apply(P1 &)
>     {
> nyi::not_implemented_error<...> err;
>         ReturnType * r = NULL
>         return *r;             // RATHER HACKY
>     }
> 
>     template <typename P1, typename P2>
>     static inline ReturnType apply(P1 &, P2 &)
>     {
>         //...
>     }
> 
>     // etc.
> };
> 
> or something more elegant, because I fear that some static code analyser
> may complain about those pointers.

I remember Bruno suggesting something on the same line to deal with the
return type of unimplemented algorithms.

> This is the intention of having this not_implemented<> class. I realize
> that there are places where some shortcuts been made and
> not_implemented<> wasn't used. Those places should probably be fixed.
> AFAIR strategies should also be derived from not_implemented<> so this
> could be checked the same way.

I agree. Then the question is more about a development schedule. I could
do my share of the work.

> I think you shouldn't be forced to think about all possible details that
> may not compile. If the algorithm and strategy are implemented for
> passed Geometries and Geometries are correct (Concept checks are for
> this purpose), everything should compile. Otherwise it's probably a bug.
> 
> Regarding the compatibility of Geometries, it could be done on the
> dispatch::xxx level. Where are those explicitly dimensions compared?

I have an example of such shortcut. I'm working on a runtime version of
the distance algorithm, moderate complexity but already plenty of
interesting problems ! In the projected_point strategy class code like
this is found :

boost\geometry\strategies\cartesian\distance_projected_point.hpp(99)

assert_dimension_equal<Point, PointOfSegment>();

>>> Btw, I couldn't find the extreme_points in intersects implementation.
>>> Where did you find it?
>> It's not a direct call. The approximative call stack is :
>>
>> intersects -> disjoint -> point_on_surface -> extreme_points
> 
> It should be used only in implementations for Areal geometries. As said,
> otherwise it's a bug.

Since my tests are instantiating the algorithms with plenty of
combinations of geometry types that may be not covered by the actual
tests, it's likely that new bugs will be uncovered.

> Well we'd be forced to probably use it (only) in not_implemented<>,
> dispatch::xxx<> and maybe some aditional classes used for reversal of
> parameters and handling of Variants.
> But with the approach mentioned above, is this Policy needed?

Sorry but what alternative are you refering to ?

>> I have setup a runtime branch on my fork and will try to add some of my
>> experiments there to make the discussion less abstract.
>>
>> https://github.com/sdebionne/geometry/commit/849fd51679f2cfb22354dab561d4f65b82159a40

I have update the branch with a test suite for the runtime version of
distance. Note that the result type is not handled correctly yet. I will
get inspiration from the length algo that already has variant support
(and variant result type).

> Thanks for your effort!

Well, I believe that should be helpfull to implement things like spatial
extension of SGDB. I'm wondering if the MySQL team has already a
solution for this...

Samuel