Andrii Sydorchuk wrote:
Apart from topology information it's usually useful to be able to associate some information with the primitive (vertex/edge/cell). At the moment this is implemented via mutable void pointer
Phil Endecott wrote:
This void* "user data" thing is something that I commented on before. It struck me as a rather old-school "C" way of doing things. If this contribution had been subject to a full review as a new library I believe it would not have been accepted in this form. I see it as a weakness of the Boost process that this has "slipped through", i.e. we have different rules for additions to existing libraries even when they are by different authors and have little or no dependency on the existing work.
Nothing has slipped through. It isn't on the release branch yet. The reason we are talking about it on the list is to get feedback for changes the community would like to see made before it is released. Apparently there is already use of Andrii's core algorithm inside google, and use of metaprogramming at google is restricted. They won't use the library through the Polygon interfaces because of the MPL dependency. Presumably the void* pointer interface already has usage and Andrii may be reluctant to change it for that reason. The macro allows us to de-feature the void* pointer in boost usage without requiring a fork of the code. Alternately we can simply not document the void* interface and view it as an implementation detail for internal use in implementing voronoi based algorithms. The third option is to bite the bullet and implement the template based solution I suggested previously. Upon reflection it seems ridiculous to recompile a complex algorithm for no good reason to make it composable with an unrelated pointer type. I typically use an index instead of a void* pointer, but I don't really see one as being much better than the other.
Having briefly experimented with Andrii's code, I have since them implemented an incremental constrained Delaunnay triangulation using Boost.Graph. This has some problems of its own, but it neatly solves the issue of per-vertex or per-edge user data via template parameters.
I'd be interested in learning more about this. Are you willing to share the code or at least expand a little on your description? Regards, Luke