Robert Osfield wrote: > Well I have no clue what you are specifically thinking of changing so > I can't say anything about it either one way or the other. The > osg::Array classes already use templates, and are already extensible, > so I don't what you're trying to address.
Well, I'm not aiming at the osg::Array classes. I'm proposing a way to make more osg::Vecnxx classes. For example, we have osg::Vec2d and Vec3d, 2 & 3 versions of b, f, and s for byte, float and short. My code called for a Vec2ul that would contain a nice doublet of unsigned long coordinates (in practice there were used to atomically store an X and Y subscript for an array, but they're not limited to that). The design of the osg Vec classes is nice, because they each provide a common set of clear operations, so I just adapted osg::Vec2b (I think) into 2ul. What I'm asking is, if I create more variants of these to flesh out the types, would you accept them into the osg codebase even though osg itself is not currently using them? And the second part of the question is, if it's a good idea to do this, would it be a good idea to study the current design of the Vec classes to see if we could make it into one or two templates. This would mean that osg::Vec2d and Vec2f might simply be implemented as instances of a common osg::Vec2real template, and b, s, ul and other integer types would be made from a common osg:Vec2integer template. The motivation here is that there is a lot of copy & paste code between the Vec classes, and if we're expanding the classes further, it will only get worse. > Robert. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
