3 ms·
#include <map> is hardly going to work at the first insertion that will call the allocator. The argument "let's use a castrated language to avoid mistakes" fal
by shin_lao 15y ago
#include <map> is hardly going to work at the first insertion that will call the allocator.
The argument "let's use a castrated language to avoid mistakes" falls short. What about communication within the team?
Properly used and tailored, the STL is extremely adequate to kernel development. The power of the template engine enables the compiler to do some very clever optimizations.
More information: http://www.osronline.com/article.cfm?article=490 http://www.osronline.com/article.cfm?article=490
- gsg 15y agoHuh? That link claims "The STL will not work in kernel mode and cannot be used", which is not much of a surprise given the STL's use of exceptions and dynamic allocation. In any case, kernel guys seem to prefer their data structures in intrusive style rather than the container style ubiquitous throughout the C++ standard library. (For an example, see the intrusive list and red-black tree implementations in the Linux kernel.) Intrusive structures allow for exactly the kind of low allocation, very memory friendly layout that kernel developers are looking for - no clever optimisations necessary. C++ features like stronger type checking, more careful casts and RAII are a more compelling argument for the language.
- cbsmith 15y agoIntrusive structures can be done in nice clean ways in C++. See policy based design.
- gsg 15y agoSure, I wasn't arguing against C++.
- njs12345 15y agoIndeed, I've seen a talk from Bjarne recently where he said that by considering what is required to make RAII work in the presence of exceptions you can basically derive the entirety of C++..