Boost logo

Boost :

Subject: Re: [boost] Formal Review: Boost.Polygon starts today August 24, 2009
From: John Phillips (phillips_at_[hidden])
Date: 2009-09-01 23:54:23

Andreas Fabri wrote:
> Hello,
> ...
> What is the overall strategy in the Boost
> project for accepting
> new topics for Boost ?

   Hi, Andreas. I'll give one person's opinions in answer to your questions.

   I would say there is no set process, and no clear guidelines. The
measures used most are about perceived need in the community, and
ameanebility to a generic solution that is suitable for a broadly used
library. The first is judged by the interest level of developers inside
and outside Boost in the project. The second is judged partially by
experience and partially by the library provided. That is, many of the
Boost developers have done enough generic work to have some intuition
for what problems are well suited to a generic solution, and this drives
some of their work. However, if someone shows up with a good generic
solution to a problem no one thought could be done that way before
seeing the code, then the response is pleased acceptance of the solution.

   This is not enough for a Boost library, yet, but it is a good start.
Coupled with clear design, solid cross platform coding, thorough testing
and well developed documentation this start becomes what Boost wants
from a library.

> First, it seems strange to me that something as specialized as 45 degree
> polygons is considered
> to fit in, what I consider as the mission statement of Boost :
> ...

   The review is not yet completed, so the decision may be that it does
not fit in Boost. However you might be missing the forest for the trees.

   Many Boost developers (myself included) think a good geometry library
would be a solid addition to Boost. It is an area that allows generic
solutions, that has some very persnickety details that are very easy to
get wrong, and that is applied in a large number of different problem
and application domains.

   Given that starting place, the real question of the moment is whether
Luke's library is the right geometry library for Boost. One feature of
Luke's library is the inclusion of specialized implementations for the
45 and 90 degree polygons. It is a feature that may not be useful in
many interested domains, but is very important in the domain for which
the library was originally designed.

   If this was all the library could do, then it would not be a good
candidate for Boost. However, many libraries include optimized routines
for specific use domains along with the more generic foundation. I see
nothing wrong with it.

> When I say specialized, obviously something like boost::optional also
> solves a specific problem,
> but it is completely independent from a particular application domain.
> Boost.Polygon seems
> rather related to VLSI and PCBs, and the only criteria it fulfills is
> the license choice.

   If, in the opinions of the reviewers and review manager the decision
is that this library does not extend usefully outside the realm of VLSI
and PCBs, then I would expect the result to be rejection. However, if it
currently has broader applicability and the review process makes it
clear how that can be built on to cover many of the needs in the field
then those are points in the library's favor during the review.

> Second, I am wondering about, when you add a first geometry related
> library without having the blue-print
> for "Geometric Computing in Boost", how can you hope that it will ever
> grow into a coherent whole?
> best regards,
> andreas fabri

   Boost isn't a centrally controlled work from a pre-approved blue
print project. Any blue print for geometric computing, or for any other
extended topic in Boost is the responsibility of the developers who
bring a proposal to the table. In the case of a geometry library in
specific, one reasonable line for questions in the review is about how
the choices in this library affect the options for adding other features
that make sense as part of the core library, as well as building
non-core features on top of the provided facilities. Once again, if the
views of the reviewers and the manager are that Luke's library design
cuts off important growth in the future then the library is unlikely to
be accepted. However, providing concepts and abstractions that ease such
expansions are a strong positive for the library.

   As stated before, this is one person's opinions and should not be
taken as anything else. I still hope to review the library and so I may
provide my own list of pros and cons for the design, implementation, and
documentation. This is not that list. When I mention pros or cons above,
they are by way of a thought experiment example, and nothing more. Take
it for what it is worth, but I hope that helps.


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