2009/6/1 James Killian <james_kill...@hotmail.com>: >> The real question is -- does boost even offer a smart pointer type that >> replicates >> ref_ptr, or is all this a pointless exercise? > > I've stepped through ref_ptr code before and it does seem similar to > intrusive and perhaps shared as well. I have also discovered a few matrix > classes that are public one of which is optimized SSE and SSE2, where some > of the benchmark code pointed out a standard to work with them among several > offered (including Microsoft's). > > The most attractive thing about standards like std::, boost, and tr1, is > that they are tested extensively by a wider c++ community and so they must > be pretty darn robust and more versatile, but more important if you are like > me and code for more platforms other than osg, you'll find it extremely > useful to be able to transfer knowledge of one standard and apply it to > multiple projects with completely different environments. > > > James Killian > ----- Original Message ----- From: "Chris 'Xenon' Hanson" > <xe...@alphapixel.com> > To: "OpenSceneGraph Users" <osg-users@lists.openscenegraph.org> > Sent: Sunday, May 31, 2009 8:21 PM > Subject: Re: [osg-users] osg::ref_ptr<> used anymore > > >> Judd Tracy wrote: >>> >>> Boost only needs to be installed if you use certain features. Shared >>> pointers is not one of those features in which it needs to be >>> installed. >> >> I like boost myself, and have used parts of it in different projects. >> But, I want to >> clarify the sense of "installed" here. >> >> I'd differentiate the multiple meanings of "installed" into >> headers-installed and >> libraries-installed. To use any part of boost in your code, you (the >> person compiling the >> boost-using project) must have the boost development kit with headers >> installed. This is >> one component that OSG doesn't currently require. It's pretty version-safe >> -- generally if >> you require boost x.y.z, any version > than that should be fine. >> >> Judd is right in that most of boost does its magic at compile-time and >> doesn't need >> binary libraries at link-time. >> >> However, it seems it is still possible to get in trouble when you mix >> binaries compiled >> by different people who used different versions of boost -- whether they >> were using >> compile-time or link-time portions of boost. >> >> Because OSG incorporates other third-party libraries (such as Collada) >> that incorporate >> boost and are difficult for individual OSG developers or the project >> maintainers to >> recompile every time something changes, we've run afoul of this problem >> and are gun-shy. >> >> The real question is -- does boost even offer a smart pointer type that >> replicates >> ref_ptr, or is all this a pointless exercise? >> >> -- >> 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 >> > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
Paul, The reason why people think boost is big probably because they misinterpret "library" word. Some certain type of developers I saw (I worked with those before) wants to understand everything about piece of code written by others, which sometimes may not be possible, if one doesn't: * know language that advanced * know the purpose exactly * have the experience required to implement such a thing I can't name project exactly, but it was a set of template classes trying to address a common problem nearly entire team was having problem with. Current implementation was to use bunch of macros, and #ifdefs. The reason behind this language level approach was to remove as many of those preprocessor garbage away from the actual source code - because we (2 devs) believed it's difficult to read and debug the code (you can't set breakpoint to next few lines, because you don't know whether that macro was defined before). It turned out that some devs believe our template solution could defect readability of source code. I didn't push much but during an informal conversation kindly asked with coffee in our hands in a cold winter's day; did you walk through std::map's source code before? It's a well known, well documented, standard and perfectly readable code! He said "no, because I don't think STL code is readable either". He probably can't read Windows SDK source code either, but _uses_ it. Everybody has different skills at different levels and may have emphasized different aspects of software design/implementation. But libraries aren't meant to be _read_, they are to _used_. Chris, the discussions wasn't about comparing boost's smart pointer cllasses to OSG's intrusive osg::ref_ptr - that'd be comparing two different things. It's perfectly possible to replicate of an intrusive smart pointer as well (pass those ref counting member methods as template arguments, define policy if you have any - e.g. conversion to pointer-to-T is implicit: has_implicit_conversion). I wanted to emphasize; Boost is not a heavy library, if you do not use certain features, and smart pointers are among those free classes. Boost must be downloaded, of course. So does OSG and may be jpeg, libpng, and so on. They too better be compiled on the development machine, since it may cause same side-by-side library problems as well. I encourage people to use Boost because it addresses most problems nicely. As you pointed out, it's a pointless exercise to compare anything in boost to something in osg; but that wasn't my point either :) Somehow conversation biased towards that direction. Ismail _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
