Subject: Re: [geometry] [multi] Merging multi
From: Menelaos Karavelas (menelaos.karavelas_at_[hidden])
Date: 2014-05-06 15:25:24
On 06/05/2014 08:33 Î¼Î¼, Adam Wulkiewicz wrote:
> 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.
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.
> And the first question.
> If you agreed, should files in geometry/multi/ be left for backward
My personal opinion is yes (at least for now, and for a few boost
> 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).
> Geometry mailing list
Geometry list run by mateusz at loskot.net