Using C++11 by default

Norman Feske norman.feske at ...1...
Mon Mar 25 19:09:55 CET 2013

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.


Dr.-Ing. Norman Feske
Genode Labs ·

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list