如何在 Windows 内核中使用 std::map？ STL端口？答案

【问题标题】：How to use std::map in Windows kernel? STLPort?如何在 Windows 内核中使用 std::map？ STL端口？
【发布时间】：2013-01-28 08:07:03
【问题描述】：

在我最近的项目中，强烈需要像std::map 这样的数据结构。但是，std::map 的默认实现使用 C++ 异常，这在 Windows 内核中是不允许的。

我认为很难在短时间内重新发明std::map 而没有任何错误或性能损失。所以，我想知道Windows内核中是否存在std::map的替换。

STLPort 可能是候选者。但我不知道如何仅提取其std::map 并禁用 C++ 异常。

【问题讨论】：

Judy 和 EASTL 是首先想到的两件事。使用vector 迭代器失效规则自己编写一个应该非常简单明了。
map 抛出了什么？我所能看到的是，如果你的分配器或比较对象抛出它会抛出（你可以自己提供这些），但否则什么都不会抛出，不是吗？
@Dave，编译器会生成异常处理代码，这与拥有自己异常机制的 Windows 内核不兼容。与运行时是否抛出异常无关。
尝试在禁用异常的情况下编译，不要使用map::at?如果您的默认分配器抛出异常（我不知道它是否会），您可能还必须将分配器替换为不抛出异常的分配器。是的，使用std::vector 编写关联容器很容易：如果您的map 使用的是“填充地图，使用地图”而不是“添加、删除、使用、添加、删除、使用、清洗、重复”，则@基于 987654333@ 的关联容器比 map 快得多，并且使用的内存更少。

标签： c++ windows stl cross-platform kernel

【解决方案1】：

内核模式下的 C++ 代码有几个（严重）限制，这些限制先于没有（完整）标准库的问题。

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

虽然目前无法为用于内核模式代码的“完全安全”的 C++ 子集提供严格且可测试的定义，但对于通常安全的构造和通常不安全的构造，可以使用一些有用的指南.

和

内核模式驱动程序的 C++ 问题

Microsoft 开发人员已发现 C++ 对内核模式驱动程序存在特殊问题的许多领域。

内存中的代码

使用 C++ 编写内核模式驱动程序最严重的问题是内存页面的管理，尤其是内存中的代码，而不是数据。它大型驱动程序可分页很重要，分页代码并不总是在记忆。所有需要的代码必须在系统进入不能分页的状态。

C++ 编译器为非 POD 类和模板生成代码的方式使得知道所有需要的代码在哪里变得特别困难执行一个函数可能会失败，因此很难安全地编写代码可分页的。编译器至少自动生成代码以下对象。这些对象被“脱节”了，开发人员已经无法直接控制插入它们的部分，这意味着它们可能会在需要时被调出。

编译器生成的代码，例如构造函数、析构函数、强制转换和赋值运算符。（这些通常可以明确提供，但它需要注意认识到需要提供它们。）

Adjustor thunk，用于在层次结构中的各个类之间进行转换。

虚函数thunk，用于实现虚函数调用。

虚拟函数表 thunk，用于管理基类和多态性。

模板代码体，除非明确实例化，否则在首次使用时发出。

虚函数表本身。

C++ 编译器不提供直接控制位置的机制这些实体被放置在内存中。控制内存所需的 pragma 布局的设计并未考虑 C++。

库

在创建和使用库时有许多不同的问题：

导出的 C++ 函数的名称可能因版本而异。

并非所有在用户模式下可用的函数都在内核模式库中可用。

标准模板库旨在处理来自单个 DLL 的数据对象。

【讨论】：

默认情况下，驱动程序的代码总是驻留在非分页内存中；除了那些明确声明某些代码是可分页的，即#pragma alloc_text(PAGE, ...)。
@xmllmx “默认”是重要的部分。但是，如果您知道您的函数只会在 DISPATCH_LEVEL 以下运行，那么您真的想将其标记为 PAGED_CODE() 并注明 #pragma。

【解决方案2】：

如果您环顾四周，您可能会找到 std::map 的替代方案。为什么需要 std::map，它是你需要的哈希表吗？然后你可能会使用uthash，它是一个已实现的哈希表。

【讨论】：