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

From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-10-05 13:06:41

On 10/5/07, Joel de Guzman <joel_at_[hidden]> wrote:
> 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.

Well, the above code doesn't work for heterogeneous vectors.  So
regardless of his opinion on introducing dependencies, it one wishes
to support heterogeneous vectors, I think one should probably just
bring in Fusion.

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

I haven't had a chance to mess around with Fusion yet, but if it could
somehow be integrated into the attached, I think we would have the
best of all the worlds.

-all the goodies that come with a Fusion sequence
-array access when the vector is homogeneous
-swizzle syntax
-doesn't rely on non-standard behavior
-zero (to very little) overhead - I would love if someone who knew asm
well could look at the generated instructions in the attached (with
optimizations on) and confirm this.

--Michael Fawcett

P.S. - I had to rename the extension to get it passed our firewall,
but it's a .zip file, so please rename it.  I can also upload it to
the Vault if that's easier.