Jean-Sébastien Guay wrote: > This doesn't really help you, but I wanted to be more detailed than just > saying "I agree".
Thanks for th insight, everyone. I'm kind of an old-school C-flavor programmer, so my instinctive response is rather C-like. I don't like bloating people's in-memory objects, so I'd lean towards defining a 32-bit flag member on class Node called something like _ephemeralInternalStateFlags. This would not be saved or restored, and the definitions of each flag bit would be enumerated as 1<<n enums in the Node class header. Code outside of the OSG core distribution would be prohibited (by policy, can't really enforce it in the compiler) from defining and utilizing these flag bits, but code within OSG core could. The first bit allocated would be used to replace the NeedToRemove indicator. Also, while the read-modify-write cycle used to toggle just one bit of a flag is not as fast as the blind-write cycle used when you dedicate a whole boolean variable (and consume more memory), both the setting operation AND the testing operation should be faster than the current string-marking technique. If Robert has no objections to this solution, I'll code it up quick and share it. I'm also concerned about the amount of very similar-but-not-quite-the-same code between DatabasePager::capped_removeExpiredSubgraphs and DatabasePager::expiry_removeExpiredSubgraphs. I'd like to refactor that to DRY (Don't Repeat Yourself) it out a bit as I'm implementing some code of my own that needs to cleanly dispose of some PagedLOD children. But, I don't understand why there are differences in the disposal technique between them (one calls _fileRequestQueue->updateBlock() directly, one sets a local flag and calls updateBlock() at the end of the operation, etc). > J-S -- 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
