Subject: Re: [boost] [Review] We're halfway through the GGL review
From: Fabio Fracassi (f.fracassi_at_[hidden])
Date: 2009-11-15 14:48:19
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:
typedef multi_polygon<polygon_3d> polygon_set_3d;
union_inserter(poly1, poly2, std::back_inserter(ps));
but got this error:
error: no matching function for call to
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk