Re: [boost] [Review] GGL review starts today, November 5th

Subject: Re: [boost] [Review] GGL review starts today, November 5th
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2009-11-22 15:45:00

2009/11/5 Hartmut Kaiser <hartmut.kaiser_at_[hidden]>
>
> -------------------------------------------------------
> 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