Barend Gehrels wrote:
Hi Fabio,
Thanks for your interest and for reviewing our library!
polygon p1 = ...; polygon p2 = ...;
polygon_set ps1 = make_union(p1, p2); polygon_set ps2; intersection(ps1, p2, ps2);
The polygon_set is implemented as a multi-polygon within GGL (and indeed you can call it polygon_set, if it fulfils the concept). We didn't merge the Multi* concepts into the generic algorithms, in other words, we don't require anyone to use a multi* (of course algorithms can be used for multi*).
Ok I read about multi* in the docu, but didn't make the connection. I also find the ggl/multi/... includes somewhat surprising. Maybe you can use them in one of the examples, to make things clearer.
Therefore, union and intersection work with output iterators. So: union_inserter(p1, p2, std::back_inserter(ps1));
Hm, I tried: #include <boost/ggl/ggl.hpp> #include <boost/ggl/geometries/cartesian3d.hpp> #include <boost/ggl/multi/geometries/multi_polygon.hpp> #include <boost/ggl/algorithms/union.hpp> ... typedef multi_polygon<polygon_3d> polygon_set_3d; polygon_set_3d ps; polygon_3d poly1; polygon_3d poly2; union_inserter(poly1, poly2, std::back_inserter(ps)); but got this error: error: no matching function for call to 'union_inserter(ggl::polygon_3d&, ggl::polygon_3d&, std::back_insert_iterator<ggl::multi_polygon<ggl::polygon<ggl::point<double, 3ul, ggl::cs::cartesian>, std::vector, std::vector, true, std::allocator, std::allocator>, std::vector, std::allocator> >)' Am I doing something wrong?
It is possible that there will be a "intersection" and "union_" as well, detecting if ps1 is a multi-polygon and automatically inserting. But that is more a sort of synonym, similar way to do things.
Yes, I know just a bit of syntactic sugar, but IMO it makes the interface much easier to use. Besides I would probably not call it union_ but geometric_union or some such, but thats just personal preference.
The make_union would require an r-value and if C++0x is there, it can be implemented without copying the whole resultset. Indeed, it fits into the design and naming conventions.
Of course, still I like this syntax best, as it is most natural.
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.[...] I understand. Several people have addressed this so we will certainly improve the documentation. Thanks for your structure proposal.
Fine, while I was further investigating ggl docu I found another wish: For each class/function add a short usage example including all relevant includes (something short like the snipplet above) This makes it immediately clear how things work together. Regards, Fabio