When I read that it immediately made me think "policy based design". Would there perhaps be some way to make the iterator policy based? Then the user could use a core::tree::iterator<core::recursive>, or a core::tree::iterator<core::level_based>, or even a core::tree::iterator<core::reverse_level_based>. You could provide the more common iterator policies with your library. I don't know mechanically how this would be implemented, its just a thought.
That's a very interesting idea Jason, one I hadn't thought of (due to my own perceptions of how the iterators would be designed). Using a policy based design for the different iterator types might just work and that actually would fit more inline with "enabling the tree creator" than anything I've thought of. I've done a couple policy designs in the past, allowing different encryption algorithms to be replaced as the policy for this cool licensing thingy and they've worked wonderfully. At the moment, I can imagine your idea of a policy based design working very well for the iterator implementation. I'm going to ponder over Rene's commentary some more and see if we can't figure out some high level plan of attack before going back to more low level thoughts. Great stuff. =) Justin