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

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-10-07 18:51:49

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.
> 
> 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?

The thing is, you can never have a one-size-fits-all point type.
Some folks say they need heterogeneous dimension types. If you
use arrays, then you can't have those. And how about legacy types,
need for higher dimensions, Etc.

So, again, use concepts! And use them all the way! Don't generalize
on concrete point types like above! You can't. Use concepts. An elegant
concept hierarchy for points should satisfy all the needs for all
users. And, there can be interoperability between different models
of the unified point concept.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net