Re: [boost] [GTL] - geometric template library - determining interest

From: François Duranleau (duranlef_at_[hidden])
Date: 2007-10-07 13:10:41

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.

Is something like

     p.x() * p.x() + p.y() * p.y()

really that much worse than

     p.x * p.x + p.y * p.y

? Is it really such a pain to write? Is the latter really more readable 
than the former?

When I write code using points, I actually seldom have to use directly 
those accessors. I am not talking about writing the point class, but using 
it. How often do we have to use something else than functions/operators 
(norm, +/-/*, etc.) on points in complex expressions?

-- 
Francois Duranleau