Subject: Re: [boost] [Review Request] Inclusion of the Boost.Polygon Voronoi Library
From: Andrii Sydorchuk (sydorchuk.andriy_at_[hidden])
Date: 2012-05-21 06:04:03
On Sun, May 20, 2012 at 11:16 AM, Jeffrey Lee Hellrung, Jr. <
> Doesn't Boost.Graph have something similar via Boost.PropertyMap? I'm not
> very familiar with Boost.Graph so I'm completely guessing here :/ But, at
> least, it sounds similar to the problem that Boost.PropertyMap is trying to
> address (IIRC, it's been a while since I've gone through the
I could probably miss something about Boost.PropertyMap.
But it doesn't look different from using a hash table to associate data.
> Well, that makes it difficult for 2 different uses of the Voronoi
> algorithms, one which has additional data and one which doesn't, to coexist
> within the same application, right?
If both are required, nothing stops the user from implementing the second
> I can see this maybe being nontrivial to work out clearnly. Is it possible
> to use derivation to your advantage here? E.g., each vertex structure, with
> some template parameter controlling its associated data, inherits from a
> common base class, and the other structures contain pointers to this base
I guess we try to avoid inheritance for the basic data structures, because:
1) it increases size of the data structure by a pointer to a virtual
2) it results in a performance dropdown for the virtual function calls;
3) for this case it doesn't seem to solve design problems.
> It seems to me like the inability to use both options within the same
> application is a serious restriction. Do you consider that not a realistic
> use case?
It could be realistic for some cases. And if it is, nothing stops the user
from providing his own voronoi diagram data structure with primitives
configuration via voronoi diagram traits.
> Also, please pardon any glaring ignorance on my part as I'm not familiar
> with this additional component to Boost.Polygon!
I am happy to discuss any details that would improve library design.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk