Boost logo

Geometry :

Subject: [ggl] combine
From: Barend Gehrels (barend)
Date: 2011-02-27 08:29:26

Hi Adam,

Thanks for your thoughts!

On 27-2-2011 13:17, Adam Wulkiewicz wrote:
> Barend Gehrels wrote:
>> Nearly all functions conform to the std:: library. std:: library defines
>> first input iterators, then output iterators, then other values.
>> e.g.
> Isn't scheme used only in relation to iterators? For objects that are
> references/pointers to some object in the collection.

Often yes. But Boost.Range does the same thing,

> E.g. streams are allways the first parameter.
> out& operator<<(out, data)
> in& operator>>(in, data)
> boost::asio::read(socket, data)
> boost::asio::write(socket, data)
> Probably because they're stand-alone objects, different from data and
> the order is simply taken from method call syntax.
> stream.some_method(data);
> In addition to his, we could write:
> stream << data1 << data2 << ...
> stream.do_something(data1).do_something(data2) ...
> So it's natural that streams are the first parameter.

Good point.

> Considering the function name. If we have functions combine, connect,
> join the order, there should be some similarity between the
> parameters. The order doesn't matter because take similar objects and
> return something connected/combined/joined. The next thing is that our
> function may have the name combine or combined.
> Our syntax would look like this:
> Box combined(Geometry const & geometry, Box const& box)
> Geometry3 combined(Geometry1 const & geometry, Geometry2 const& box)
> or
> void combine(Geometry const & geometry, Box const& box, Box
> &expanded_box)
> void combine(Box const& box, Geometry const & geometry, Box
> &expanded_box)
> it doesn't matter if the box is first or second because the result is
> in the third parameter, something combined.

Actually the current signature and behaviour is not that it combines 2
geometries, but that it expands the box to cover the additional geometry.

So the idea is to call it in a loop, see
(where it is not a loop but the idea will be clear).

> But if we have the name corresponding to one of the objects, e.g.
> expand, IMO it should be on the first place because the name
> corresponds to it.
> expand(box, something);
> box.expand(something);
> or maby
> box.expand(something1).expand(something2)
> box << something1 << something2 ... // this looks a little odd

Nice sample. Calling a method on a box is not possible for us. Because
we're concept based and .expand is not part of our concept, and often
not part of a legacy rectangle.

Returning a box would be possible.

box = expand(something, box).

Actually this is probably better because both input arguments are const
then. So can be reversed indeed.

So something like:
box = make_envelope<Box>(something); // determines initial bbox
box = expand(box, other thing 1);
box = expand(box, other thing 2);
box = expand(other thing 3, box);

One of them must be of type box otherwise... the output type is now known.

> on the other hand
> Box Box::expanded(Geometry const& something) const
> Box expanded(Box const& box, Geometry const& something);
> But, it all depends on how we think of the box.
> In the computer graphics and game programming areas this operation is
> named expanding and the box is referred as aabb (axis alligned
> bounding box).

I know aabb indeed. Maybe expand is the best name. Thanks.

Regards, Barend

Barend Gehrels

Geometry list run by mateusz at