use*_*696 15 c++ kernel stl intrusive-containers
C++的假设是"你用的是什么,你付出的代价".然而,由于例外情况及其在STL中的普遍使用,这可能会非常虚弱.
在任何人说"只是打开异常"之前,生活对于我们必须生活的编程环境并不那么慷慨.我的是内核编程,其中执行环境没有提供足够的C++运行时来展开堆栈等.
当STL容器无法为其底层后备存储重新分配存储时,它们将抛出分配失败异常.当在环境中没有启用异常时,程序将会相当神秘地崩溃:我已经看到实现直接中止或只是假设分配工作即使它没有.
我遇到的许多C ADT库都是通过返回错误代码或将错误作为输出参数来提前解决此问题.
处理这个问题的"最佳"C++方法是什么?
我不想使用标准库,我不能.我不是在问"我怎么做那些无法做到的事情".我问:"考虑到一个干净的平板,如何建造容器库."
Nic*_*las 18
这很容易:不要相信你应该使用标准库来做所有事情.
标准库旨在成为您实现功能的默认位置.但是,这并不意味着它适用于所有情况.例如,内核编程.这是一个相当小众的环境,您需要直接和明确地控制大多数C++程序员不关心的事情.
信令失败的C++标准机制,特别是来自容器的内部内存分配之类的东西,就是抛出异常.绝大多数应用程序都不会理会这个例外; 万一他们失去记忆,他们就会死.哪个对他们没问题.在这些情况下返回错误代码是最困难的(考虑重新分配a std::vector<std::string>.如果其中一个内部std::string是得到OOM 会发生什么?谁得到错误代码?你怎么会发出构造函数失败的信号,因为异常是由std::strings拷贝构造函数引发的?).只有真正需要关心的人才会关心它.
您正在受限制的环境中工作,这是一个标准库无法处理的环境.所以...不要在那种环境中使用它.
我的建议是追踪一份EASTL.它真的是为这种东西而设计的.我链接到的Github repo有一些错误修复等等,但它仍然大致相同.这不是一个糟糕的代码.他们的类似STL的容器提供了大部分接口,因此它们可以主要是直接替换.但它们提供特殊功能来专门控制内存分配.他们不扔(或至少,你可以关掉投掷).
| 归档时间: |
|
| 查看次数: |
6150 次 |
| 最近记录: |