8

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.

Improve this question
4
  • 3
    Judy and EASTL are the first two things that come to mind. Writing one yourself with vector iterator invalidation rules should be pretty straightforward and easy. Commented Feb 12, 2013 at 21:43
  • what in map throws? All I can see is if your allocator or compare objects throw it would throw (and you can provide those yourself), but otherwise nothing throws, does it? Commented Feb 12, 2013 at 21:50
  • 1
    @Dave, The compiler will generate exception-handler code, which is not compatible with Windows kernel that has its own exception mechanism. It has nothing to do with whether throwing an exception at run-time. Commented Feb 12, 2013 at 21:57
  • Try compiling with exceptions disabled, and do not use map::at? You might also have to replace the allocator with one that doesn't throw exceptions, if your default allocator throws exceptions (I don't know if it will). And yes, writing an associative container using std::vector is easy: if your map use is "populate map, use map" and not "add, remove, use, add, remove, use, wash, repeat", a std::vector based associative container is much faster than a map and uses less memory. Commented Feb 12, 2013 at 22:50

2 Answers 2

Reset to default
4

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.
Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

By default, a driver's code is always resident in non-paged memory; except for those explicitly declare that some codes are pageable, i.e. #pragma alloc_text(PAGE, ...).
@xmllmx "by default" being the important part. But if you know your function is only going to run below DISPATCH_LEVEL you really wanna mark it as PAGED_CODE() and with said #pragma.
2

If you look around you should probably find an alternative to std::map. Why do you need std::map, is it a hash-table you need? Then you could probably use uthash which is a c imlemented hashtable.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.