Re: [boost] [GTL] proposal for geometry set operations

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-05-08 06:31:56

On Thu, May 8, 2008 at 8:47 AM, Simonson, Lucanus J
<lucanus.j.simonson_at_[hidden]> wrote:
> Simonson, Lucanus J wrote:
>  >>      template <typename geometry_type_1, typename geometry_type_2>
>  >>      polygon_set_view operator&(const geometry_type_1& geo1,
>  >>                                      const geometry_type_2& geo2) {
>  >>              ...tag dispatching and so forth... }
>  >>
>
> Steven Watanabe wrote:
>  >I hope that this is not the actual declaration.  Completely generic
>  >operator overloads
>  >are dangerous.
>
>  There is no declaration yet, since I haven't finalized the design.
>
>  I was thinking that it could be solved by registering the geometry types
>  for which operator overloading is safe as operator args in the
>  geometry_traits.
>
>  template <>
>  geometry_traits<UserPolygonSet> {
>
>         typedef polygon_set_concept geometry_concept;
>         typedef UserPolygonSet operator_arg;
>  };
>
>  ...
>
>
>  template <typename geometry_type_1, typename geometry_type_2>
>  polygon_set_view operator&(
>   typename geometry_traits<geometry_type_1>::operator_arg const& geo1,
>   typename geometry_traits<geometry_type_2>::operator_arg const& geo2);
>

This can't work: geometry_type_{1,2} are in a non deducible context.
You need to SFINAE on an
is_polygon_set trait. It can still break if the user class happens to
have an operator& with different
behaviour. I think you'll have an hard time using operators on user
classes without explicitly stating
that those operators are concept requirements, i.e. the user has to
explicitly define them for their classes.
Of course your library may provide shortcuts help define them more easily.

-- 
gpd