Boost logo

Boost :

Subject: Re: [boost] Formal Review: Boost.Polygon starts today August 24, 2009
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2009-08-29 20:37:05

Simonson, Lucanus J wrote:

> You could make a polygon_traits specialization for your own triangle class, but not a polygon_mutable_traits. This would allow the library to view your triangle type as a read-only polygon type.

But then my triangle would only be seen as a dynamically-sized polygon.
I'm asking how difficult it would be to enhance the algorithm so that
they can make use of the fact the polygons are statically sized (to
avoid loops, in particular).

>> Still in the static vs dynamic argument, it appears points implement
>> by default the static coordinate lookup (the x() and y() functions) in
>> terms of the dynamic one (the get(orientation_2d) function).
>> Shouldn't it be the other way around?
> The assumption here is that when the dynamic one is instantiated and inlined by the compiler constant propigation will allow it to optimize it away producing an interface without runtime overhead.

But the other way around works just as well and doesn't require the
compiler to be smart enough to do that, no?

> I agree with you about equational reasoning. Center used to return point_data. I changed it to be consistent with other interfaces and allow user defined point types.

Actually, I was thinking of maybe something like this:

template<typename T>
struct center_expression
     center_expression(const T& polygon_) : polygon(polygon_) {}

     template<typename P>
     operator P() const
         P p;
         center(p, polygon);
         return p;

     const T& polygon;

template<typename T>
center_expression<T> center_r(const T& polygon)
     return center_expression<T>(polygon);

CPolygon polygon = ...;
CPoint p = center_r(polygon);

That doesn't require any addition to the concepts, nor does it introduce
any temporaries if you assume the compiler does NRVO (which is something
done by the frontend when translating function calls, not a general
optimization, and is done regardless of whether the type is complex or not)

This is certainly not perfect, since you would need center_expression to
be a model of Point etc., but I thought that maybe it was an interesting
thing to consider.

> I can't say I prefer
> ref(A) | ref(B)
> to
> A | B

Well, it's more

ref(A) | ref(B)


     using namespace boost::polygon::operators;
     A | B

Boost list run by bdawes at, gregod at, cpdaniel at, john at