2009/11/5 Hartmut Kaiser <hartmut.kaiser@gmail.com>
------------------------------------------------------- Everybody on this list is invited to participate in this formal review. I hope to see your review of this library, including your vote, and I welcome your participation in the discussions on the Boost mailing list.
Please always state in your review, whether you think the library should be accepted as a Boost library.
My Review: GGL is an ambitious project with a large scope. While it's design is well thought-out and many algorithms are probably mature, there is obviously unfinished work pending in fields that seem to be important and that are added to the library only recently. This puts me as a reviewer in a difficult situation. I have a tendency to reject the library simply because important parts are not finished. I have the impression that the rules are bent here, because the contributors mistook generic library development for a horse race. On the other hand there is a lot of substance, work and dedication in this library and the project deserves approval. So my vote is a weak YES in the end.
- What is your evaluation of the design?
The design is very clear. I think it can serve as a standard example of how to cover a big non trivial problem domain using meta programming, partial specialisation and tag dispatch to make it uniformly accessible by a set of generic algorithms.
- What is your evaluation of the documentation?
The part of the documentation I liked most was the design rationale page. It clearly describes the libraries basic design ideas step by step. The reader not only gets a good understanding of the GGL's design but is able to use these techniques in her own projects. Important parts, like that one on "set theoretic operations" have been added during the review, which nurtured the "horse race impression". The doxygen generated docs are minimal and have a few minor inconsistencies (e.g. template parameter S and Strategy within one page). Missing is a synopsis what algorithms are actually implemented for what combinations of geometries with the complexities for each such combination (or at least for the most efficiency critical algorithms). There were sometimes benchmark figures given in a paragraph "performance", but these are almost useless without a context. When I had problems with coding some toy programs the documentation appeared to be insufficient in providing the needed information.
- What is your evaluation of the potential usefulness of the library?
There is no question that a general generic geometry library is of very high usefulness.
- Did you try to use the library? With what compiler? Did you have any problems?
Used it with msvc-9. All examples worked well. Trying to run the tests resulted in some errors. Which I have not tried no analyse: ...failed updating 59 targets... ...skipped 169 targets... ...updated 279 targets... I have tried to run some toy programs and encountered problems very quickly, when I tried to initialize and use multi_polygons, e.g. ggl::multi_polygon<polygon_2d> mupo; std::cout << ggl::dsv(mupo) << std::endl; // produced this error message boost\ggl/util/write_dsv.hpp(344) : error C2039: 'apply' : is not a member of 'ggl::dispatch::dsv<Tag,IsMulti,Geometry>' Also I was not successful in assigning or appending a polygon to a multi_polygon. In the experiments, that I did with Boost.Polygon I was able to customize own classes, build a polygon generator and run law based tests within a few hours. In GGL this was not possible because of basic problems with multi_polygons.
- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Reading the documentation. Browsing some code, including test code. Trying to run some toy programs.
- Are you knowledgeable about the problem domain?
I'm not an expert in computational geometry but an experienced developer in the field generic programming. Best regards Joachim Faulhaber