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); Would this proposed solution address your concern about safety? Is there another way to make it safe that you would suggest instead? Thanks, Luke

...

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

Giovanni wrote: 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.

Oh yes, of course. How about this, keep the registration with geometry_traits, but put the use of it on the return type: template < typename geometry_type_1, typename geometry_type_2> polygon_set_view<typename geometry_traits<geometry_type_1>::operator_arg>, typename geometry_traits<geometry_type_2>::operator_arg, op_and> operator&(geometry_type_1 const& geo1, geometry_type_2 const& geo2); Since the polygon_set_view needs to be templated in terms of the arguments anyway, the indirection provides the opportunity for SFINAE to prevent conflicts with operators for types that haven't been registered for use with the gtl operators. See correctly compiling code example below for full details. If the user has an operator & with different behavior that does cause them a problem I would expect them to not provide the trait that allows the type to be used with operator syntax. That type would result in substitution failure. I also can't use the operators internally in any circumstance where the arguments may be user types since I can't rely on them being registered. I don't want to require the user to define the operators because that would lead to too much code to adapt the library to their type system. It also leaves users who have already defined the operator for a different purpose unable to use the library with that type at all, whereas there would be an alternative syntax for types that can't be used with the operators. Thanks for pointing out my error, Luke #include <iostream> template <typename T> struct A { }; struct B {}; struct C {}; struct D {}; template<> struct A<B> { typedef B operator_arg; }; template<> struct A<C> { typedef C operator_arg; }; template <typename T1, typename T2> struct operator_result { const T1& t1; const T2& t2; operator_result(const T1& t1_in, const T2& t2_in): t1(t1_in), t2(t2_in) {} void print() {std::cout << "hello world\n"; } }; template <typename T1, typename T2> operator_result<typename A<T1>::operator_arg, typename A<T2>::operator_arg> operator&(const T1& lvalue, const T2& rvalue) { return operator_result<typename A<T1>::operator_arg, typename A<T2>::operator_arg>(lvalue, rvalue); } int main() { B b; C c; (b & c).print(); D d; //the next line does not compile //because D is not registered with A //(d & b).print(); return 0; }

Fernando, Please take a look at my post with subject "operator syntax proposal checked into sandbox" in which some of your questions are answered. I'll answer the questions you wont' find answers to in that post below:'

...

The user must register their type as a polygon set type:

template <> geometry_traits<std::list<UserPolygonType> > { typedef polygon_set_concept geometry_concept; };

This is probably explained somewhere but, could you state what a

geometry_traits<T>::geometry_concept

is?

I would like better if the library used a general expression templates framework instead of a custom mechanism so it can be used in much more

just polygon set operations. But then of course, does boost has any of

It is a struct that declares all functions that relate specifically to a geometry concept. The struct is not templated so it makes a convenient tag. In the static functions of the struct the first argument is usually the templated geometry type. In this way the geometry concept can be used as both a namespace and a tag for resolving which function to call depending on what conceptual type the user's object has. The need for registration of a type can probably be dispensed with using something like enable-if, but this means I'm not allowed (by the compiler) to provide a default traits because that would not work with SFINAE. Right now all type identification is explicit and I use default traits for my own types. I'm still putting some thought into this on how it could be improved. than that

already?

I'm not sure what you mean here.

...

This proposed API is the most concise and intuitive way I can think of to provide these algorithms to the library user.

Do you mean the operator syntax or the lazy evaluation? I don't care for the former, but I certainly do for the latter, and to a broader extent.

I meant the operator syntax. The lazy evaluation is currently implemented as computing the full result of an operation only when it is used, but could be pushed further to have lazy iterator algorithms that produce the next increment of a result of an operation only when required. Whether there is advantage in doing so, however, is currently unclear. Thanks, Luke

...

...

This is probably explained somewhere but, could you state what a

geometry_traits<T>::geometry_concept

is?

Luke wrote:

...

It is a struct that declares all functions that relate specifically to a geometry concept.

Fernando wrote: Sorry, I meant to as what a "geometry concept" is? at a entirely conceptual level. I ask becasue I can't infer the meaning from the name (to it feels as it where "lucanus_concept" :)), nor from the particular

Fernando wrote: polygon_set_concept

example.

I meant that lazy evaluation is the job of expression templates and

(and should IMO) be intrumented by an *external* general framework for

geometry_traits<T> is a metafunction for looking up the conceptual type of a geometry type T. If you pass a type which is a point type the meta function should return point_concept, if you pass a type which is a polygon type the meta function should return polygon_concept. geometry_concept is just the generic name of the return value, which is why it feels generic. In this way the geometry concept is a tag, but it is also a namespace for functions to be declared in and may eventually provide concept checking capabilities, including using those check to ensure that the arguments to the functions which should model the concept do so correctly. From that standpoint I could break it up into three different things, a tag struct, a namespace for holding functions related to the concept and a concept struct that provides concept checking capabilities. On the other hand, I really like that the tag is the namespace for passing as a template parameter and it makes sense to me to provide concept checking eventually in the following manner: struct point_concept { template <typename T> struct provides_get<T> { typedef typename result_of<point_traits<T>::get> type; }; ... template <typename T> provides_get<T> get(const T& t, orientation_2d orient) { return point_traits<T>::get(t, orient); } }; Do you think it would be better to change: geometry_traits<T>::geometry_concept to: geometry_concept<T>::type to make it more obviously a metafunction? I think I may have chosen a misleading name for it, which led to confusion. Fernando wrote: that >can that

purpose, like the pioneer PETE (http://acts.nersc.gov/pete/). IOW, this shouldn't by just an ad-hoc mechanism within some portions of your library if possible.

I'm not surprised to see that other people have implemented the same basic idea. This PETE library is exactly the solution to a problem that a colleague of mine told me he was unable to solve with C++ when I explained my expression template to him and he saw that it solves it. I suppose a generic solution for expression templates could be devised that allows a functor type to be passed as the third parameter of the template, but it would also need to add a fourth template parameter for the type for the result that needs to be allocated and passed by reference into the functor to store the result. Alternately, the operation could be required to provide a lazy iterator output semantic. At that point, however, it is more generic than most people need and I fear that if such a library existed it wouldn't be very used. This is what I have in mind: template <typename l_type, typename r_type, typename functor_type, typename result_type> class lazy_evaluation { private: mutable result_type result_; mutable bool evaluated_; const l_type& lvalue_; const r_type& rvalue_; public: lazy_evaluation(const l_type& lvalue, const r_type& rvalue) : lvalue_(lvalue), rvalue_(rvalue), evaluate_(false) {} //needs to be declared const so callable from a //const reference to this const result_type& evaluate() const { //prevent redundant evaluation if(!evaluated_) { //modifies mutable result, which stores the //result of evaluation functor_type()(result_, lvalue_.evaluate(), rvalue_evaluate()); //modifies mutable evaluated member data evaluated_ = true; } return result_; } }; which factors out the expression template from my usage of it. It might make sense for me to refactor my code in this way to provide the abstraction between functor and expression template to eliminate specialization of the expression template. It may also prove useful when I implement mixed operations between axis-parallel and arbitrary angle geometry types in which the algorithms and operators selected will depend on the conceptual types of the input operands and I will need to apply the same pattern several times over. I'll need to think about it more. Thanks, Luke