Re: [boost] [GTL] - geometric template library - determininginterest

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