On 10/5/07, Joel de Guzman <joel@boost-consulting.com> 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.