Geometry Boost List: Re: [geometry] [multi] Merging multi

Subject: Re: [geometry] [multi] Merging multi
From: Barend Gehrels (barend_at_[hidden])
Date: 2014-05-06 16:27:42

Hi,

Menelaos Karavelas wrote On 6-5-2014 21:25:
>
> On 06/05/2014 08:33 μμ, Adam Wulkiewicz wrote:
>> Hi,
>>
>> Currently it's impossible to use some algorithm for MultiGeometry 
>> #including only the algorithm's header.
>> Additional functionality from geometry/multi/ directory must be 
>> included.

So: if #include <boost/geometry.hpp> is not used.

In other words, it's a problem of the unit tests, so for ourselves, and 
indeed it is sometimes inconvenient, I agree. But it is not a big problem.

Where does it go? I assume you keep separate files, so what does it 
solve? The issue is (often) that not all specializations necessary for 
the multi-implementation are available. So they should be included. 
Moving files alone does not help.

Separation into multi was done at the beginning, to support users 
needing only single geometries and not multi. However, I don't think 
that is really used. And besides, doing operations (e.g. intersection) 
often splits a single into a multi. So I basically agree with moving them.

But I think we should postpone it a bit. Especially because the release 
closure is upcoming (somewhere this month, see recent messages on the 
list about this). We should concentrate on that, or on fixing remaining 
bugs (there are several tickets open).

>>
>
> A definite +1 for this.
>
>> I propose to merge the code from geometry/multi/ directory into the 
>> geometry/ directory.
>> We could start with the core/ and then move forward.
>>
>
> I volunteer to help. We can split up the work if you want.
> On the other hand, I would prefer that we do this after I am done with 
> distances and the code is merged into develop.
>
> Also an orthogonal comment: part of the work of merging geometry/multi 
> into geometry/ is to move the generic dispatch code into separate 
> files/directories. Many multi-geometry implementations use the generic 
> dispatch in their implementation, and it must be available before the 
> details of the multi-implementations.

I would say: the dispatch uses the implementation so the details must be 
available before the dispatch. Multi implementations are currently 
modelled like that.

There are only 3 algorithms where multi uses dispatch (num_points, 
append, distance). Maybe they should derive from detail and not from 
dispatch, like all others do. So they are exceptions, not "many".

I don't see the need for separate folders for dispatch.

>
>> And the first question.
>> If you agreed, should files in geometry/multi/ be left for backward 
>> compatibility?
>
> My personal opinion is yes (at least for now, and for a few boost 
> versions forward).

I don't know if this is necessary - most (if not all) users just 
#include boost/geometry.

If we start this, please move the files, such that all git-history is 
preserved. Don't create new files and leave the old file with a warning 
only.

For multi-geometry files, I agree with a warning or #error - they were 
not automatically included so this would create a backwards 
compatibility issue.

>
>> They'd be empty, #include only the version from geometry/
>
> I am not sure there is a question here or not.
> I have already done this for distance computations in my clone 
> repository, and the multi version of distance just includes the 
> non-multi version of distance. Otherwise we risk having problems with 
> a user that, for example, uses the BG develop branch along with a 
> public release of boost.
>
>> Definietly we should handle models this way and maybe add a #warning?
>
> Adding a #warning seems like a very good idea. This way we can notify 
> users to change their code in a smooth/polite way (smooth/polite here 
> means: no breaking code).

So, in summary, basically I agree with moving, but I don't think it has 
priority and I don't think we should do it now.

Regards, Barend