|
Boost : |
Subject: Re: [boost] [Review Request] Inclusion of the Boost.Polygon Voronoi Library
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-05-21 13:33:36
On Mon, May 21, 2012 at 9:14 AM, Simonson, Lucanus J <
lucanus.j.simonson_at_[hidden]> wrote:
> Andrii Sydorchuk wrote:
>
> >The main point is that this void* data member is not used by the
> algorithm at all. And is only exposed to simplify data association with
> voronoi primitives.
>
> Does it currently have any usage at all?
>
> >From the user perspective the good practice would be to use data
> >access functions instead of direct class methods to retrieve associated
> >data:
> >template <typename T>
> >UserDataType* data(const voronoi_edge<T>& edge) {
> > return static_cast<UserDataType*>(edge.data());
> >}
>
> I guess it depends on whether the user wants to traverse the voronoi
> diagram data structure as the input to their algorithm or copy it over to
> their own graph data structure. I tend to think that copying to their own
> data structure will be pretty common. It looks like the user can look up
> the input site for each cell in your voronoi_cell data structure. If they
> hash or map the site to whatever data they want associated with the site
> they can at least make the association between the voronoi diagram and its
> input. Unless there is a compelling reason I'd suggest just removing the
> user data interface. As you mentioned, the user can always roll their own
> voronoi diagram data structure to use with the voronoi builder that they
> can extend with whatever additional data they want.
>
I may have some suggestions on how to implement this user data, but yes,
Luke's suggestion looks to be the simplest solution. Andrii, do you have an
example use case for storing the data in situ with the voronoi primitive
objects? Looking at a concrete use case might help ground the discussion.
- Jeff
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk