On Thu, May 8, 2008 at 8:47 AM, Simonson, Lucanus J <lucanus.j.simonson@intel.com> 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