Quote:
|
Originally Posted by tuxdev
Deleting a node seems like it is removing a function in a C source file, or removing a case in a switch statement, or even the switch statement itself.
|
That's pretty much how it would be for that particular application. It's got a lot more uses than that, however, and a lot more possibilities for editing structure (not in current release, though.)
Quote:
|
Originally Posted by tuxdev
I'd argue that a class that can't be used with the STL is borderline useless, and is probably reinventing the wheel again (of course, there isn't anything wrong with reinventing the wheel if that's what you aiming for).
|
The main reason it can't be used with a container is that allocation MUST be per-element and not by something that can go out of scope (except for the base element.) The reason for this is that the pseudo-tree elements can be removed, replaced, deleted, etc. arbitrarily, meaning that what was once on one "tree" can be placed on an entirely different "tree" in a different scope.
Back to something that was mentioned about having one node simultaneously on 2 trees; the nodes are the structure, and NOT the data. If the data portions of two nodes want to share a pointer to a single data location then they can do that if the user so implements.
The reason I've gone for the "linked list" style over the "random access container" style is that I intend very linear processing (much like a source code parser.) Basically how the user uses the structure is by parsing, editing the structure as necessary (they can use a parallel structure based on their implementation to figure out where they should edit), then exporting the data in a different format. The lib exports data by polling elements from beginning to end. There isn't really a need for other than "forward" (and "down") access.
ta0kira
