Boost logo

Boost :

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. <
jeffrey.hellrung_at_[hidden]> wrote:

> 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
> documentation).

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
one.

> 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
> class.

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
functions table;
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