|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk