Hi Alexander,
Btw, how about adding some "map" like container to base with a simpler interface than avl_tree and maybe based on some other data structure? (I'm not asking to do it, just wonder if you think it's a good idea). Sorry for the off-topic
I was not planning to do so. If you come up with a useful structure that leads to code simplifications at a number of places, it would be a good idea to include it under 'os/include/'. We use to grow the utilities provided there quite organically. For example, the 'Signal_dispatcher' template class appeared first in the implementation file of a single component. Because it was useful, it subsequently appeared in the implementation files of a number of other components. This tells me that it has passed the test of utility. Moving it to a central place is just natural to avoid duplicated code. In this particular case, the code ended up in 'base/include/base/signal.h'. Other examples are the 'Static_root' and 'Slave' class templates, or the path utilities.
It may be hard to match the convenience of the STL containers though. I think that STL containers should be used wherever it is acceptable to pull in the complexity of the standard C++ library and where no exact accounting of memory allocations is needed. (see the other discussion "Standard placement operator") In contrast to STL containers, Genode's data structures follow the "invasive" pattern to alleviate the need for extra allocations (and the accounting) for meta data. That is, the meta data always gets incorporated into the object. (e.g., the next pointer of a list element is stored in the same object as the list element) There are no hidden allocations. But it makes the data structures a bit awkward to use.
In short, if you have a good data structure, just use it in your component. When it is useful, it will "magically" appear elsewhere. If this happens, we will certainly move it to a central place to ease and promote its further adoption.
Cheers Norman