[boost] [polygon] Overload resolution for operators fails

Subject: [boost] [polygon] Overload resolution for operators fails
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2009-09-01 09:21:43

Hi Luke and polygonists,

trying to set up some law based tests for boost::polygon I faced difficulties
with the overload resolution of operators under msvc-9.

This is the code sniplet where the problems occur:
-----------------------------------------------------------
#include <boost/validate/laws/law.hpp>
#include <boost/polygon/polygon.hpp>
// Here I map a PolygonSet class to geometry_concepts according to
// the docs:
#include <boost/itl_xt/custom_polygon.hpp>

namespace boost{namespace itl
{
    template <typename Type>
    class PolygonCommutativity
        : public Law<PolygonCommutativity<Type>,
                     LOKI_TYPELIST_2(Type,Type), LOKI_TYPELIST_2(Type,Type)>
    {
        // a o b == b o a
        . . .
        bool holds()
        {
             using namespace boost::polygon;
             using namespace boost::polygon::operators;

            Type value_a = this->template getInputValue<operand_a>();
            Type value_b = this->template getInputValue<operand_b>();

            Type left  = value_a;
            left += value_b; // Compiler fails to find the appropriate overload
                                   // but
            // this works
            self_assignment_boolean_op<Type,Type,0>(left, value_b);
            // and also this works
            boost::polygon::operators::operator+=<Type,Type>(left, value_b);
            // and this
            boost::polygon::operators::operator+=(left, value_b);

            . . .
            return equivalence(left, right);
        }
    };
-----------------------------------------------------------

moreover, if my custom PolygonSet conainer implements
an operator += this operator is *silently* chosen by the
compiler, so the wrong addition function is called!

Contrary to the traditional understanding of a concept,
that defines *requirements* for a parameter class it
can use, we have to take care here, that the client class
*does not* implement certain operations.
I am afraid this is not a good thing.

I hope this is fixable, may be the error is on my side
but I can't see it yet.

Regards
Joachim