Hi, How far can we use the Boost.BGL as a generic tree container. * I mean why SoC Boost.Tree when BGL is around? * If BLG has limitations then couldn't that be extended/prettified instead of the Soc Tree container? * Can someone please clarify/rationalize the differences/similarities? Also I noticed that Boost.Interprocess had some sort of tree implementation. * Why the reason for this and if used internally then what is for, otherwise can't it be just made generic for everyone to use instead of the SoC Tree implementation? Thanks Shams
Shams wrote:
Hi,
Hi
Also I noticed that Boost.Interprocess had some sort of tree implementation. * Why the reason for this and if used internally then what is for, otherwise can't it be just made generic for everyone to use instead of the SoC Tree implementation?
Boost.Interprocess tree is the common code to implement shared memory map/set/multimap/multiset containers. Like the standard ordered containers, the implemented tree is a red-black tree. I just don't know if they could be useful for other project, though, Regards, Ion
On Oct 25, 2006, at 9:15 PM, Shams wrote:
Hi,
How far can we use the Boost.BGL as a generic tree container. * I mean why SoC Boost.Tree when BGL is around? * If BLG has limitations then couldn't that be extended/prettified instead of the Soc Tree container? * Can someone please clarify/rationalize the differences/similarities?
It may be possible to extend the BGL, but trees are a more restricted domain than graphs, with different terminology. A user of a tree library wants to "add_child" whereas a user of a graph library wants to "add_edge"; forcing the user to use improper terminology is more likely to force them to implement their own data structure. Also, one can probably optimize storage/traversal/etc. for a tree better than for a generalized graph data structure. That said, I'd like to see tree and graph libraries made interoperable, so that BGL algorithms can work on generic trees. Doug
participants (3)
-
Doug Gregor -
Ion Gaztañaga -
Shams