Re: [boost] any interest in a 'tree' container?

From: Kasper Peeters (peekas_at_[hidden])
Date: 2002-10-10 12:54:31

> OK, now I've read (very briefly, and not in-depth). A short comment
> about the documentation: it ends after merge, without details.

I should have added and stressed that the documentation isn't at all
meant to be complete or correct. I simply didn't have the time to
finish that.

> I can't understand how it would be useful as a data structure

As someone else has pointed out, storage of an XML tree is one such
application (that's actually why I started writing tree.hh). I am
using it to represent mathematical expressions in a computer algebra
program, to name another application. 

> If you had given the freedom to store the children as a container, say,
> you would allow implementations that store the children as an array
> instead of a doubliy linked list (which is hardwired in your design).

I thought of that but it was not obvious to me that this would
actually gain much (which of course doesn't prove anything, I know
that). I wrote this thing because I had a need for it, but I did not
want to spend ages thinking about parts of the design for which I did
not even have a useful application (that would have been pointless
anyway, in my opinion).

You can go overboard with abstraction, resulting in a library that is
too complicated to use in 90% of the applications. You can refer users
to the BGL for any kind of tree data structure, but that wouldn't be
practical: sure, you can implement trees that way, but you have to
know a lot of additional things which you wouldn't have to know if you
would just have a 'tree' class. I am sceptical about a 'one fits all'
tree class for this reason (but I'd be happy to see that I'm wrong on
this).

Anyhow, I'm sure this has been discussed here at length in other
settings, maybe someone should point me to the right parts of the
mailing list archives to catch up with it.

> It's very likely such problems would crop up during a formal review
> so I thought I might echo them in advance to prepare you for what's
> to come.

Sure, I understand that.

Kasper