Boost logo

Boost :

Subject: [boost] [Review Results] Boost.Polygon library accepted into boost
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2009-11-05 10:21:32

Dear Boosters,

[first of all allow me to apology for not doing this before. My small consulting
bussines suddenly grew out of proportion and now is way over my head, keeping me
working/managing 16 hours a day]

I am pleased to announce that the Boost.Polygon library from Lucanus Simonson
has been accepted into boost provided some of the most critical concerns,
detailed below, are addressed first.

First of all I would like to thank Lucanus and Intel Corporation for making this
work available to all C++ developers around the world.

I would also like to thank all the reviewers that participated (in no particular
order nor degree of participation)

Thomas Klimpel
Frank Mori Hess
Barend Gehrels
Andreas Fabri
Jeffrey Hellrung
Tim Keitt
Markus Werle
Paul A. Bristow
Robert Stewart
Mathias Gaunard
Michael Fawcett
Steven Watanabe
Joachim Faulhaber
John Bytheway
Sebastian Redl
Mika Heiskanen
John Phillips
Kai Benndorf
Hartmut Kaiser
Arash Partow
Maurizio Vitale
Brandon Kohn
David Abrahams
Gordon Woodhull
Daniel James
John Maddock
Tom Brinkman
Bo Persson
Mateusz Loskot
Christian Henning
Jean-Sebastien Stoezel

The library had 6 yes votes and 4 no votes.

Those who voted no made the following major complains and remarks (they are
numbered as I will refer to them back later):

Barend Gehrels:

   According to his benchmarks, intersection algorithms are unnecesarily slow
   as if something where fundamentally wrong in the design and/or implementation.
   AFAICT the implication has not been proved or disproved so far, hence I
   consider it a red herring and cannot take it as a reason for rejecting
   the library, but it is important to look at it in detail.

   As a major complain, the library is unusable in those domains where
   floating point support is a requirement (like GIS).

   The library should contain some basic polygon geometry algorithms
   such as convex hull and centriod

Phil Endecott:

   There is no concept checking in the code so it is difficult to adapt.

   There where too many warnings and build errors (but Luke fixed these)

   The documentation needs a better overview of operations supported by
   the concetps.

   It also needs the details on the algorithms complexities.

   It also misses the numerical requirements for the coordinate type.

   And tutorials.

   Some operators are ambiguous and it would be better to keep just one of each

   The polygon_data template class is parameterized by a coordiante type rather
   than a point type. This makes it useless for integration with existing
   geometric data types

Michael Fawcett:

   (5), (6a), (6d)

   T9he API should provide versions using output iterators in addition to output
   container references.

   Theoreticall the library would be usable with a user defined coordinate
   type (metting certain requirements now undocumented), for example a fixed
   point data type, but some details in the internal design and
   implementation prevents this.

   As a major complain, the library is unusable in those domains where
   floating point support is a requirement (like GIS).

Hartmut Kaiser:

   (11), (1)

Fernando Cacciola:

   The name of the library should change to better indicate that is
   restricted to Integral coordinates and two-dimensions.

   The documentation must contain a "credits" section acknowledging all the
   people that participated in the review.

For the library to be effectively accepted, points (5),(6a-d),(10), (12) and
(13) should properly addressed ((5) is already done AFAICT)

It would be quite significant if point (1) where looked into.

Once again I thank Lucanus, Intel Corporation and all the reviwers.

Best regards

Fernando Cacciola
SciSoft Consulting, Founder

Boost list run by bdawes at, gregod at, cpdaniel at, john at