In my opinion, the field pClone_fcn should be a member variable of basic_tree<>. We can not assume all trees are using the same memory model. It is very realistic that a tree or subtree has its own allocator. In the most complicated case, for example: A tree (using default allocator) has 2 main branches (subtrees), one employs malloc/free allocator, the other employs user-defined FastAllocator, I don't think there would be any confliction.
Now, I'm trying to make your TCL as difficult to be used as I can. ^_^ The basic_tree will be like this:
template< typename key_type, typename mapped_type, typename tree_type, typename container_type >
class basic_tree;
and container_type will be instantiated to std::map/std::multi_map. If I succeed, my tree may become a useful complement to TCL. Portability is not my main concern. Support for gcc3, dev-c++ 4.9, VC7.1, VC8.0 compilers is enough.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my opinion, the field pClone_fcn should be a member variable of basic_tree<>. We can not assume all trees are using the same memory model. It is very realistic that a tree or subtree has its own allocator. In the most complicated case, for example: A tree (using default allocator) has 2 main branches (subtrees), one employs malloc/free allocator, the other employs user-defined FastAllocator, I don't think there would be any confliction.
Now, I'm trying to make your TCL as difficult to be used as I can. ^_^ The basic_tree will be like this:
template< typename key_type, typename mapped_type, typename tree_type, typename container_type >
class basic_tree;
and container_type will be instantiated to std::map/std::multi_map. If I succeed, my tree may become a useful complement to TCL. Portability is not my main concern. Support for gcc3, dev-c++ 4.9, VC7.1, VC8.0 compilers is enough.