> For good reasons. As said before a tree is an implementation detail. When having a fully implemented C++ STL one really seldomly needs an explicit tree implementation. Of course, there are special cases which are speed/memory sensitive which require to implement explicitly a tree but in this case a generic tree is probably also the wrong choice because it does not allow the hand crafted optimizations needed in such cases.
This is what I see from the POV of C++ STL designer, while I take Boost POV. I agree with Michael, and I implement this to leverage tree as more than just backend of some container (e.g. set and map) to stand as a container on its own. Isn't it a good idea to have a tree that can act as both backend and be used standalone? From tree, graph can also be built (but I'd rather separate the implementation to have tree optimized version of the traversal algorithm, no need to check for "mark as visited"). -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/State-of-fcl-stl-generics-lib-tp5712537p5712606.html Sent from the Free Pascal - General mailing list archive at Nabble.com. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
