Barend wrote:
Besides this, in the past discussions concerning the previous previews,
and the other submissions, discussions concentrated on the points. How it was modelled and how it should look like. Until now I didn't saw any
comments on this (besides construction of generic geometry objects). Can we conclude that the list is now satisfied with the provided point concept?
template <> struct access<example_point_1> { template <int I, typename PP> static typename forward_const<PP, typename support::coordinate<example_point_1>::type>::type& get(PP& p) { return I == 0 ? p.x : p.y; } }; No, not really. First of all, what about constructing and setting values of the point? It appears to be missing from the generic interface. Also, your get function returns a reference to coordinate. It should return by value. Many legacy point types may have a public API that prohibits direct access to their members because that is what good little C++ programmers were taught to do in school. Those point classes could not conform to your concept. A polar coordinate point could give a Cartesian coordinate view of itself, but not if it has to return is Cartesian coordinate values by reference. It could not conform to your concept either. A point is not a tuple. I don't think it is valuable that tuple conforms to your point concept. An interval has a low and high value, could be implemented as a tuple of size two, and would incorrectly conform to your point concept. That's not a good thing. If you had an interval concept in your geometry you would have to ensure that it was different from the point concept in some way. Since you are defining traits for your geometry objects, why not define their conceptual type as a trait? template<> struct geometry_concept<example_point_1> { typdef point_concept type; } This takes the guess work out of things and allows you to do tag dispatching based on conceptual type. Luke