On Thu, Oct 2, 2008 at 9:07 AM, Robert Osfield <[EMAIL PROTECTED]>wrote:
> Hi Neil, > > We've had similar submissions in the past by previously I haven't > merged due to problems with old compiler not compiling the code -I > have even written similar methods myself only to have to remove them > later due to compile errors on other systems. Having an optional > compile path is a possibility, but it would mean that code that > compiles on a modern machine being ported to an older machine could > fail as methods it relies upon won't port. > Robert, I didn 't think for a moment that this was something you couldn't have done yourself. I suspected that the issue was compiler support and that I would have to try to convince you to allow some conditional compilation so that those of us with half-decent compilers don't pay the penalty for those horid evil non-compliant compilers. Hopefully by now conditional compilation will not be necessary. Let's see. > > Perhaps developers interested in full portability could use a CMake > option to switch on/off the new methods, so be able to spot problem > usage under modern systems before they port over to older systems. It > would be worth exploring these issues again as well. We no longer > support VS 6.0 which was one of the problem child, the other is SunOS > compilers and MipsPro, the these later two can handle your code > unmodified then we might be able to get away with no optional compile > which is by far my preference. > It's always my preference too. > > W.r.t using of boost smart pointers, this would be possible but the > payload is the dependency on boost and the breaking of backwards > compatibility, so it might be an interesting academic exercise but > isn't one that will be integrated in OSG-2.x. > I personally have no motivation to add boost pointers. I was attempting to help another poster. It is actually possible to allow interoperability with boost::intrusive_ptr without introducing a dependency on boost! We just have to add two non-member functions that are then found through argument dependent lookup. I'm not sure how the older compilers will handle this though. It would allow others to use intrusive pointer with classes derived from osg::Referenced. To be honest though it is probably better to write generic algorithms that are pointer independent and use the non-member functions and meta-programming type generators to implement the algorithm. In this way the generic algorithm can work for all pointer types. I'll only do this if people would like it. I doesn't seem nearly as compelling as the template copy constructor and template assignment. I'm not one for doing work for no reason! :-) > > Steps next would be to see how well the proposed code ports onto SunOS > compilers and MipsPro. Mathias? Any chance you could try a build on an > old IRIX and Sun box? > > Cheers, > Robert. > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
