On Sun, May 20, 2012 at 11:16 AM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung@gmail.com> 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.