François Duranleau wrote:
On Sun, 7 Oct 2007, Dave Harris wrote:
It misses this one:
template <typename T> class Point3 { T v[3]; public: T &operator[]( size_t i ) { return v[i]; } T &x() { return v[0]; } T &y() { return v[1]; } T &z() { return v[2]; } };
which in my view is the only way to fly. It has no run-time overhead (provided the trivial functions are inlined). It does not rely on non-standard or non-portable features. It's simple and easy to understand. It has the added benefit that the underlying representation is kept private, and all access done via member functions.
The main drawback is the extra brackets. cout << p.x();
rather than: cout << p.x;
Which is a pain, but I think the benefits are worth it.
I was beginning to wonder when finally someone would bring this one. I totally agree that this is the best option, and I personnaly don't understand what is the big fuss about adding the extra parenthesis.
FWIW I also totally agree with you both. On both accounts.
Fernando Cacciola
IF I was writing a 'point' class I certainly would have it work that way, but I am interested in notation that should support generic algorithms right? You can provide whatever additional syntax you like, but I want to know what is reasonable to _require_ of a point class. It seems clear that bracket (runtime indexed) syntax has problems for some folks, and that compile-time indices (get<0>) has problems in other cases, and that Boost.Fusion seems to provide a way to deal with both cases in generic code. The named access functions (x(), y(), z()) can be convenient except that they are not even indexed by a compile-time integer, if that matters. Which compilers still don't support the at_c<N> syntax? I have heard others say that was not portable before, but I have used libraries that used this syntax on g++ 3.4.2 and VC8. Basically after looking at Fusion a bit, I am satisfied with the folks who argue in favor of satisfying Fusion concepts for point coordinates. I am ready to worry about IF and how boost would accommodate the other semantics of a 'point' concept. As the GTL author seems to have pointed out in their explanation of "isotropic", a point is a point regardless of its coordinates, and perhaps a point concept should involve the coordinate-free operations that make sense on a point versus a vector etc., and another concept/term should be adopted for the set of coordinates. If the GTL authors have such concepts I am curious to see the interplay of point, vector, and coordinate_sets (or whatever they are called). -- John