Re: [boost] Formal Review: Boost.Polygon starts today August 24, 2009

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;
     }

private:
     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)

against

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