$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [Review] GGL review starts today, November 5th
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-11-22 13:44:06
Hi Pierre,
> [...] and that something simplier could even work : instead of a variant, a tuple of back_inserter could do the trick very nicely.
>
> vector<point2D> myPoints;
> vector<line2D> myLines;
> vector<polygon2D> myPolygons;
>
> typedef tuple<vector<point2D>, vector<line2D>, vector<polygon2D> > AFakeTupleType;
>
> intersection_inserter<AFakeTupleType>(poly1, poly2, make_tuple(back_inserter(myPoints), back_inserter(myLines), back_inserter(myPolygons));
>
> Please note there is no object of type AFakeTupleType constructed. This type is just used to drive the algorithm.
>
> The output can be dispatched to different vectors, and the input is still 1 object. Then, the user can simply check the lenght of each result to check if there was an intersection.
>
> This is less mathematics oriented, but still completely usable, and more simplier, because of the redirection of the result to the
> selected vectors.
>
> You already use tuple, so maybe references wrapper in AFakeTupleType would be needed to make the distinction with your other tuple.
>
> What do you think of that? Do you see any drawbacks?
>
I think it will work. It would certainly solve the performance issue,
you get all three collections back in one calculation.
Potential drawbacks (or, better stated, issues):
- it is more complex; I think (personally) that most users want only the
intersected polygon back. To always require the complexity described
here might be a bit too much
- but that is no real problem, because we can create another function
for it, or even automatically detecting what is happening here, in the
tag dispatching
- the AFakeTupleType (tuple of vectors) does not match the make_tuple
(tuple of output iterators), as you said
- but also that is no real issue (actually, it is the same as it is
working now, the OutputType and the output iterator)
I think it is feasable and a very good idea; but not by default (because
of the complexity involved, also for the library user). But if people
want to get all these three different things back, yes, I think this is
the best option discussed until now. Does the trick very nicely, as you
said, indeed. Thanks!
Regards, Barend