Subject: Re: [boost] [Review] We're halfway through the GGL review
From: Fabio Fracassi (f.fracassi_at_[hidden])
Date: 2009-11-15 09:53:10
here is my review. I followed all the discussions since your first
preview, because I am interested in a good geometry library.
I liked your initial design and was really impressed by the cooperative
improvement during the iterations.
But before going into details, I think that GGL should become a part of
boost, so make this a Yes vote.
> - What is your evaluation of the design?
I think it is clean and easy to follow.
The one exception to this is the way union / intersections are handled,
which I have not fully understood yet.
I would have expected to be able something along the lines of:
polygon p1 = ...;
polygon p2 = ...;
polygon_set ps1 = make_union(p1, p2);
intersection(ps1, p2, ps2);
I also don't find it too obvious how the extention to 3d geometries is
going to work, yet.
> - What is your evaluation of the implementation?
I have only skimmed through it, but it looks quite clean. It is easy to
find each entity, and see what they are doing.
> - What is your evaluation of the documentation?
On the whole I am very pleased with the documentation, its easy to read
and reasonably complete.
I have a general problem with doxygen generated docu with regard to
generic libraries. It not easy to separate the important classes and
fuctions from the implementation details.
GGL helps with this through Grouping by modules and a overview Page, but
it could be even better. I think the Modules should them self be
further grouped, and the most important should be highlighted. Something
along the lines of (just examples, no informed reordering):
Coordinate Systems (?)
Algorithms (? Functions)
Utility / Machinery
And ideally (but I think that it is not feasible in doxygen) better
Navigation inside these Groups
> - What is your evaluation of the potential usefulness of the library?
I think it is immensely useful to have this in boost. An example like
qt_example shows that geometry plays a role even in everyday programming
and is not specific to any particular (niche) domain. I think it is
important that we have a common vocabulary which scales form there to
very complex and involved algorithm.
I would love to have it extended to 3d Geometry (especially
Polygon/Triangle meshes) but I wouldn't make my vote depend on this.
However I think that 3d should become part of the default distribution
once it is there.
> - Did you try to use the library? With what compiler? Did you have any
Compiling some example and playing around with them a bit. No problems
on OS X 10.6 with gcc 4.2.1
> - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?
As stated above reading the Docu, and all communication on this list
from the get-go. Glancing at the Implementation, and trying out some
> - Are you knowledgeable about the problem domain?
Yes, I work in medical visualisation, and have developed geographical
tools while studying. I have used CGAL and (unfortunately) ACIS and
evaluated a few others, so I have a good Idea what a c++ geometry
library should or should not look like.
Kind regards, and great Work
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk