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

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-10-05 02:15:10

Simonson, Lucanus J wrote:
> John wrote:
>> What is not lightweight about the get<0>(pt)  syntax? Doesn't it
> compile
>> away? Is the issue a dependency on another library -- because the
>> get<0>(pt) syntax seems really easy to provide without bothering with
>> Fusion. 
>>
>> i.e. 
>> template <int Index> float get(MyPoint & p) {return p[Index];}
>> OR
>> template <> float get<0>(MyPoint & p) {return p.x;}
> 
> Dependency is an issue, since my library depends only on the STL, which
> ships with the compiler and compiles currently in gcc 3.2.2, 3.4.2, and
> 4.2.1; icc 9 and 10 and most painfully Visual Studio 2003/2005.  The
> barrier to adoption into a legacy build system is extremely low.  Adding
> a dependency, even to a boost library, would actually hurt my ability to
> integrate it into legacy applications.

Right. Ok. That's a valid concern.

> Moreover, the technique you are proposing works fine at compile time,
> but won't work if the axis of the coordinate you are accessing is a
> runtime parameter:
> int my_axis = 0;
> get<my_axis>(pt);
> will throw an error.  We specify the axis we access at run time.  If we
> specify a constant it should compile away and be light weight.  gcc
> 4.2.1 still needs us to play with the compiler flags to get decent
> inlining.
> pt.get(orient.getPerpendicular()); //orientation determined at run time.
> My scanline algorithm actually parameterizes the orientation of the
> scanline at runtime, so you can sweep left to right or bottom to top.

Ok. Well, then if accessing the index using runtime int is a requirement,
then your only option is an array of some sort indeed.

Minus one for genericity. Forget structs, tuples, interoperability
and adoptation of other systems. Forget heterogenous dimensions.

Hmmm. Seems like this type of rigid API is not to my taste. To me it's
like requiring that all STL containers be indexable with ints. Perhaps
there's merit in limiting the library this way. Extreme performance?
Sure, ok, but then again, what really amazes me are libraries like
GIL, or STL that provide extreme performance without being rigid.

My opinion only.

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