Boost logo

Boost Announcement :

Subject: [Boost-announce] [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
has been accepted into boost provided some of the most critical
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
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
  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
  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
  type (metting certain requirements now undocumented), for example a
  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
  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
Unsubscribe & other changes:

Boost-announce list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at