A better idea was to use a std::list of std::list. But then an issue arise: this is an embedded platform (Windows CE), and the way we manage memory in the software is horrible (I didn't wrote that part. Someone believed that having memory pools which are created by memory pool managers which are managed by a higher level memory pool manager manager was the way to go; of course, it's slow, and you have no control on memory allocation. But hey, that's a The Memory Manager). Writing an allocator was my first idea (so I did it). Suprise, the code was awfully slow.
No optimization (allocatiopn strategies) of the memory manager helped. Oops.
Finally, after I spent two days on that issue, I decided to go the Old Way: I did my own n-ary tree class, without using the STL. Me. A fervent supporter of the SC++L. I did code something that looks like a linked list of a linked list (and, to help readability, I didn't even followed the SC++L idiom).
I feel ashamed.
Better news: "SOMETHING" goes better and better, here is another excerpt.
When listing responsibilities, avoid using verbs whose meaning is unclear and too general. Such verbs encompass "to manage", "to handle" and many more. The obvious reason is that since their meaning is unclear, they won't express a real semantic in your design and you're likely to face problems due to this. Avoiding these verbs has also a neat consequence: there is no more Manager classes in your design, something which turns out to be quite positive. What does a manager do anyway? Does it create or destroy things? Does it store things? Does it cache them? It's often easy to find a better verb to describe what you want to accomplish.
Cookies to the one who can tell me what all this is about.