|
Boost : |
Subject: Re: [boost] [Review Request] Inclusion of the Boost.Polygon Voronoi Library
From: Andrii Sydorchuk (sydorchuk.andriy_at_[hidden])
Date: 2012-04-10 18:51:45
>
> Well this is interesting. I've looked some more at your docs and I see
> that you really haven't used e.g. Boost.Polygon's Point concept at all.
> Instead you have your own concepts; IIUC, having read the "Basic Tutorial"
> page, your Point concept requirement is
To make it clear there is no such thing as Boost.Polygon.Voronoi Point. The
library would work with any point class that supports x() and y() access
methods at the moment.
So I'd be interested to know what has happened in this case. Is it simply
> that the extra work to use the generic style is too much to ask of the
> author? (At the time of the review, I had the impression that this style
> was making life unreasonably difficult for potential library contributors,
> but I think I was convinced by others that this was worthwhile in order to
> get more uptake in existing code.) Or is there some other factor that I've
> missed?
I didn't consider this before as this will require just one small change in
the Voronoi builder initialization method. So if this is a permanent
requirement for the inclusion I'll do the proper updates. On the other hand
I really like current interface as it is very simple and allows to
construct Voronoi diagram with one include header and two lines of code. I
am wondering if there is a solution that will satisfy both sides. For
example changing default implementation of point_traits:
template <typename T>
static inline coordinate_type get(const T& point, orientation_2d orient) {
return point.get(orient);
}
to:
template <typename T>
static inline coordinate_type get(const T& point, orientation_2d orient) {
return (orient == HORIZONTAL) ? point.x() : point.y();
}
This will support my current template interface that accepts anything with
x(), y() methods by default and won't break functionality of the Boost
Polygon library. Am I right?
Regards,
Andrii
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk