From: Dan Rosen (dan.rosen_at_[hidden])
Date: 2005-03-30 01:48:40
Hi Andreas,
Sorry for the delayed reply.
> Well, From my point of view these three aspects are important, I
> already had uses for that in my applications. E.g. sometimes std::set
> could be improved by if you know that the key space is restricted. Then
> I would appreciate the fact that such a library exists, allowing me to
> reuse lots of code, and just adding my special optimization.
Good point. I think there are a large set of uses I wasn't
considering, where the user of this tree is not writing some arbitrary
domain-specific code, but instead is writing a general container! For
example, I wasn't considering using this tree as a basis for
implementing std::set.
I am kind of on the fence as to whether I should consider this type of
scenario or not. It certainly seems appealing in some ways, but I have
to admit, I don't have even remotely enough experience with template
metaprogramming to have an intuition for the drawbacks. Would you mind
writing up a little bit more description of the
advantages/disadvantages of Jeff's approach? I'd really benefit from
having a better understanding there.
> ... the untangled tree template paper by
> Matt Austern, Stroustrup et al. included them too.
Where can I find this?
> Due to the orthognal views, I beliebe a
> combination of both efforts could create a really versatile overhead free
> tree library. Even though you do not need the features cited above,
> there are people that would like to use them, and there is still more
> that can be done with the library.
You may be convincing me :) My feeling was that the feature-oriented
approach seems like a lot of trouble to go to, to support a fairly
homogeneous set of uses, but if we consider supporting container
implementers in addition to general users, the uses become far more
diverse. Additionally, your scenario here:
> Lets say someone wants to serializer a big tree into a file, but not
> keep the full tree in memory.
... convinces me that the distinction between users with "specialized"
needs (such as container implementors) and the average user is not so
black-and-white.
I'll keep working through Jeff's code to try to understand it better.
If you wouldn't mind, could you please send me a link or two to any
other documents you think would help me put this code in context?
Thanks very much!
dr