To STL, or not to STL?

[evoex]

Hi everybody,

I'm using C++ for my OS. Not to its full extent: I won't use virtual functions much in the kernel, for one, especially not in the performance-critical sections of the kernel.
Now, I've read some posts (here and on other places) that C++ OS's shouldn't use the STL, though other people seem to disagree. What are the advantages and disadvantages, in your opinion?

For me, I find the STL extremely well designed. The classes are extendible for cases that sound brilliant in a kernel, such as the custom Allocator class for containers before memory allocations are available through standard methods. Through the use of templates I can imagine it to be faster even than the C alternatives in some cases. Also, there are many implementations, so I could simply just port a very decent one, saving loads of work, and it being more optimized than I could ever make it...
Of course, there are some portions of the STL that don't make sense to have in the kernel. Examples are cout, err, cin and fstream, and there are a few more. But it's easy to simply leave those out...

So, what are the arguments to use, or not to use, the STL?


Thanks in advance

[Combuster]

The argument argument always boils down to the following: The more advanced the technology, the easier it is to break in a hostile environment, and the more arcane it becomes to fix it if it does break. If you truly know what you're getting at, you can use any library in the kernel, use any language. Most people are however incapable of that, and it is for those people we have rules of thumb like "don't #include anything you haven't written yourself" and force them to use a cross-compiler because it goes some length to enforce that rule.

Pretty much any STL implementation was designed to compile and run atop of a C library. Violating assumptions like that typically trigger hidden features or otherwise have interesting consequences. The question to be asked is whether or not you skills have been trained enough to handle those moments.

[evoex]

Thanks for your answer! That actually sounds like quite a fun challenge...

But I did forget that I'd also have to implement exceptions, and for that RTTI, etc. I don't think it's possible to use many classes from the STL without support for exceptions... And using exceptions everywhere probably is somewhat of a performance overhead, is that right?

[Combuster]

Exceptions are designed to be exceptional - therefore their implementation is made such that performance cost is only paid each time one is triggered, with little to no performance hits on the normal order of things.

As for the practical technicalities, my OS is written in a higher level language and lacks most C++ support so I can't do much more than pointing you to google and the wiki.

[JamesM]

Thanks for your answer! That actually sounds like quite a fun challenge...

But I did forget that I'd also have to implement exceptions, and for that RTTI, etc. I don't think it's possible to use many classes from the STL without support for exceptions... And using exceptions everywhere probably is somewhat of a performance overhead, is that right?

Yes, it does.

When an exception is taken, expect a severe slowdown and emptying of cache as the DWARF automaton attempts to trawl the stack.

Also expect a large binary size because of all the exception tables.

[dozniak]

Shouldn't it be the Dwemer Automaton? *wink*

[OSwhatever]

I do not use the STL library in the kernel because it is not suitable. In the kernel you want to use intrusive algorithms in order to reduce small fragment allocations and also for speed. GNU libstdc++ also requires that you have several posix calls implemented or stubbed. After linking, the binary becomes something like 400KB without your code included which is far too big for a kernel.

STL library is great for user space but I would avoid it in the kernel. Boost intrusive algorithms on the other hand could be worth having a look at.

[dozniak]

libstdc++ isn't the only STL implementation, and perhaps not the best one.

[evoex]

Thanks for your answers, everybody!

I do not use the STL library in the kernel because it is not suitable. In the kernel you want to use intrusive algorithms in order to reduce small fragment allocations and also for speed.

For this reason I guess I could use custom allocators.

But to be honest, the severe slowdown of exceptions doesn't sound like it's worth the hassle... So I don't think I'll use the STL.

[Griwes]

I think we should stop this misuse of the "STL" term; I guess no-one here wants to use an old and deprecated library now that it is contained in C++ Standard Library, does he?

[evoex]

I think we should stop this misuse of the "STL" term; I guess no-one here wants to use an old and deprecated library now that it is contained in C++ Standard Library, does he?

Hmm, I didn't find your link very convincing. But to be fair, searching through the C++ standard doesn't produce any results... So I guess he does have a point.

I don't think of the STL as the entire C++ Standard Library, though. Just the "template library" that contains the containers and everything to do with the containers. As in, the library of templates that are part of the standard. Or the Standard's Template Library .

But fair enough, I guess I should drop the term.

[OSwhatever]

Thanks for your answers, everybody!

I do not use the STL library in the kernel because it is not suitable. In the kernel you want to use intrusive algorithms in order to reduce small fragment allocations and also for speed.

For this reason I guess I could use custom allocators.

But to be honest, the severe slowdown of exceptions doesn't sound like it's worth the hassle... So I don't think I'll use the STL.

The custom allocator isn't really enough. Most STL algorithms do extra allocations for the containers, usually small structures which will add memory consumption and fragmentation. Intrusive algorithms are the most appropriate for kernels. In practice you get two allocations or more for every object you insert. In a kernel you want to be able to control this more and reduce the allocations. Another reason you want to have your own implementations is the ability to change the "kernels" which is the algorithm kernel in this case. What comes now are the lock transition buffers for lock less algorithms in multicore systems. When you have your own, you will be able to adjust these kernels for the architecture.

The STL algorithms that use containers are great for user space and they are more versatile and generic but it comes at a cost too. I'm not saying it is impossible to use standard STL for kernel programming it's just that they are not efficient in terms what you'd want with system programming.