Boost logo

Boost :

From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2007-10-07 17:56:53

> 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


Boost list run by bdawes at, gregod at, cpdaniel at, john at