[boost] [GTL] operator syntax proposal checked into sandbox

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-05-14 17:51:31

I have completed initial implementation of the operator based syntax I
proposed for polygon set operations (Booleans) and hooked up the actual
algorithms and data structures to that API.

You can see the complete pattern in the sandbox:
http://svn.boost.org/trac/boost/browser/sandbox/gtl/gtl

The operator&() declaration now looks like this:

template <typename geometry_type_1, typename geometry_type_2>
polygon_set_view<typename geometry_type_1::operator_arg_type,
                 typename geometry_type_2::operator_arg_type,
                 boolean_op::BinaryAnd, 
                 typename geometry_type_1::operator_storage_tag, 
                 typename geometry_type_2::operator_storage_tag> 
operator&(const geometry_type_1& lvalue, const geometry_type_2& rvalue)
{
  return polygon_set_view<geometry_type_1, geometry_type_2,
    boolean_op::BinaryAnd, 
    typename geometry_type_1::operator_storage_tag, 
    typename geometry_type_2::operator_storage_tag>
  (lvalue, rvalue, 
   polygon_set_traits<geometry_type_1>::orient(lvalue), 
   boolean_op::BinaryAnd());
}

In explanation of what is going on, the polygon_set_view just takes a
const ref of each of its arguments and performs the actual algorithm
only when its member function is called asking for the result, which it
returns by reference because the view has a member to store the result
of the algorithm.  This has the nice side benefit of eliminating an
unnecessary copy that would normally occur if the operator function
returned the result of the algorithm by value (which could be very
large.)

An interesting feature of this design is that the polygon_set_view can
accept an polygon_set_view in its geometry type template parameters
leading to recursive template instantiation.  You can see that in the
test case below where the template instantiation recursion depth is
equal to the number of chained operator calls made in a single
statement.

The drawback of the design is that I'll need to overload the operator
functions to allow the user to register their own data types as operator
arguments since the user geometry type can't be expected to provide a
typedef for operator_arg_type.  The overloaded operator would use a
metafunction that registers the user type as an operator_arg_type.  This
leads to four declarations for each operator since either or both
arguments can be of one flavor or the other.
 
If you drop this miniature test into a cpp and compile against the gtl
header files you should see that the compiler handles things nicely.
I'm using gcc 4.3.0 to get maximal standard compliance.

#include "gtl.h"
int main() {
  polygon_set_data<int> ps1, ps2, ps3;
  ps1 | (ps2 | ps3);
  (ps1 | ps2) 
    | ps3;
  ps2 * ps1;
  ps1 & ps2 - (ps3 + ps1) ^ ps2;
  return 0;
}

I have also changed the point_3d_concept to inherit from the 2d point
concept and the polygon_with_holes_concept similarly inherits from the
polygon_concept.  This leads to a very convenient ability to produce
polymorphism of generic geometry types.

There are still a few more algorithms that need to be hooked up before
the prototype of the re-implemented library is complete, but I wanted to
ask for feedback now so that I can get early course correcting advice.
The design is still in a state of flux.

Thanks,
Luke