Question

In my recent project, a data structure like std::map is strongly demanded. However, the default implementations of std::map use C++ exceptions, which is not allowed in Windows kernel.

I think it is hard to reinvent std::map in a short time without any bug or performance penalty. So, I want to know whether there exists a substitution of std::map in Windows kernel.

STLPort may be a candidate. But I don’t know how to extract its std::map only and disable C++ exceptions.

Answer 1

C++ code in kernel mode has several (severe) limitations that precede the issues of not having (full) standard libraries.

See http://msdn.microsoft.com/en-us/library/windows/hardware/gg487420.aspx

Although it is not currently possible to provide a strict and testable definition of the “completely safe” subset of C++ for use in kernel-mode code, some useful guidelines are available for constructs that are usually safe and those that are usually not.

And

C++ Issues for Kernel-Mode Drivers

Microsoft developers have discovered a number of areas where C++ presents particular problems for kernel-mode drivers.

Code in Memory

The most severe problem with using C++ for writing kernel-mode drivers is the
management of memory pages, particularly code in memory, rather than data. It
is important that large drivers be pageable, and paged code is not always in
memory. All of the code that will be needed must be resident before the
system enters a state in which paging cannot occur.

The way the C++ compiler generates code for non-POD classes and templates
makes it particularly difficult to know where all the code required to
execute a function might go and thus difficult to make the code safely
pageable. The compiler automatically generates code for at least the
following objects. These objects are put “out of line,” and the developer has
no direct control over the section in which they are inserted, which means
they could happen to be paged out when needed.

• Compiler-generated code such as constructors, destructors, casts, and
  assignment operators. (These can often be explicitly provided, but it
  requires taking care to recognize that they need to be provided.)
• Adjustor thunks, used to convert between various classes in a hierarchy.
• Virtual function thunks, used to implement calls to virtual function.
• Virtual function table thunks, used to manage base classes and polymorphism.
• Template code bodies, which are emitted at first use unless explicitly instantiated.
• The virtual function tables themselves.

The C++ compiler does not provide mechanisms for direct control of where
these entities are placed in memory. The pragmas necessary to control memory
placement were not designed with C++ in mind.

Libraries

There are a number of distinct concerns in creating and using libraries:

• The name of exported C++ functions can vary from one release to another.
• Not all of the functions available in user mode are available in the kernel-mode libraries.
• The Standard Template Library is designed to work with data objects from a single DLL.