HI Chris, OK, I understand better where you coming from now - making a template of Vec to enable easier implementation of the various implementations.
I chose not to use templates in the first place to avoid the compiler doing too much work on such a commonly used class and to enable easier specialization to the specifics of each type. Given I chose not to use templates for these classes in the first place, and my experience of maintaining these separate implementations has been very straight forward, they've existed without changes for quite some time, then I do see there a critical issue to change. I believe "If it ain't broke don't fix it" is a good motto follow in this case. Robert. On Fri, Aug 7, 2009 at 4:28 PM, Chris 'Xenon' Hanson<[email protected]> wrote: > 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 > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
