Geometry Boost List: [ggl] Proposal for Delauney triangulation algorithm

Subject: [ggl] Proposal for Delauney triangulation algorithm
From: Bruno Lalande (bruno.lalande)
Date: 2011-10-28 00:52:55

Barend, Luke,

>I agree that maintaining two versions is not a good idea, so wrapping
> >the Voronoi with interfaces sounds as a good approach. I've seen
> >screenshots and a presentation on Andrii's work but don't know the
> details.
>
> It may have changed recently, but last I looked the core algorithm
> implementation didn't depend on my SFINAE based interfaces and could be
> included directly without including the rest of Polygon.  You could then
> wrap that without having to include any of the header files that contain
> SFINAE based interfaces that don't compile on non-compliant compilers.
>

I don't think that should prevent us from building bridges between our
libraries.

In terms of dependency: it doesn't make Boost.Geometry *depend* on
Boost.Polygon but *able* to work with it. Once this adaptation exists,
Boost.Geometry is still completely independent from Boost.Polygon, as it is
obvious that if somebody wants to use this adaptation, he obviously has its
target (Boost.Polygon) already in place. Otherwise, why not state that
Boost.Geometry depends on std::pair because there's a point concept
adaptation for it...

Same for platforms. The fact that Boost.Polygon compiles on less platforms
than Boost.Geometry doesn't immediately reduce the field of platforms
Boost.Geometry is compatible with as soon as it integrates an adaptation to
Boost.Polygon. Again, it's just a tool and by definition a developer who
needs it *is* already running on a Boost.Polygon compatible platform. So the
limitation is not implied by the Boost.Geometry adapter.

In general, glue code stuff lives somewhere in-between what it sticks and
doesn't imply any dependency and/or field reduction for any of the parts. I
think I pointed this out some time ago on the Boost list when I proposed a
Boost.Python function that makes a Python tuple from a Fusion sequence and
was answered I was introducing a dependency between Boost.Python and
Boost.Fusion...

Regards
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20111028/7fa03dc3/attachment.html