Geometry Boost List: Re: [geometry] [multi] Merging multi (dispatch)

Subject: Re: [geometry] [multi] Merging multi (dispatch)
From: Menelaos Karavelas (menelaos.karavelas_at_[hidden])
Date: 2014-05-07 05:27:13

Hi Barend.

On 07/05/2014 12:09 μμ, Barend Gehrels wrote:
> Hi Menelaos,
>
> Reacting on my own fragments:
>
>> 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".
>
> These 3 are explicitly marked by dispatch namespace, calling dispatch 
> from non-dispatch namespace. Indeed there are more, calling their 
> single version from dispatch namespace. For some it is indeed quite 
> convenient that it is modelled like that.
>

I agree about the convenience part. I was not suggesting to change that: 
on the contrary, I like this approach, and because of that I wrote what 
I wrote (that the primary/non-specialized dispatch template should go in 
a separate file).

>>
>> I don't see the need for separate folders for dispatch. 
>
> Having the primary template in a separate file and let all 
> specializations be more self-contained, having their own 
> implementation and dispatch specializations, can indeed make the 
> structure more modular. However, if we go for that (needs more 
> discussions), I really prefer to postpone this, it requires splitting 
> all files, moving classes around, maybe even more.
>

We have had some private discussions on this, and the outcome, AFAIR, 
was to put the primary dispatch template in a separate file under a 
dispatch/ directory.
This way in the main file we can have all includes at the top and the 
implementation afterwards, and, more importantly, within the library we 
will be able to eliminate dependency cycles.

Anyway, I agree that we need more discussions, and in any case expose 
the "problem" and the possible solutions to the community, and get feedback.

BTW, the code I am writing for distance computations follows this model: 
there is no separate multi implementation, the primary dispatch is in a 
separate file in the algorithms/dispatch directory, and implementation 
details are separated into files, each containing not only the details, 
but also the dispatch specializations. It can serve as a working example 
of what we are going towards to, and we can use the experience gained 
from it for the other parts of the library.

- m.

> Regards, Barend
>
> _______________________________________________
> Geometry mailing list
> Geometry_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/geometry