以下句子中的术语模块指的是什么?
不允许异常跨模块边界传播。
这是Herb Sutter 和 Andrei Alexandrescu在C++ 编码标准中的第 62 条规则。
我现在已经阅读了这本书,所以我想引用部分摘要,我认为这会增加一些清晰度:
不要往邻居的花园里扔石头:C++ 异常处理没有普遍的二进制标准。除非您控制用于构建双方的编译器和编译器选项,否则不允许异常在两段代码之间传播;否则,模块可能不支持异常传播的兼容实现。通常,这归结为: 不要让异常跨模块/子系统边界传播。
以下句子中的术语模块指的是什么?
不允许异常跨模块边界传播。
这是Herb Sutter 和 Andrei Alexandrescu在C++ 编码标准中的第 62 条规则。
我现在已经阅读了这本书,所以我想引用部分摘要,我认为这会增加一些清晰度:
不要往邻居的花园里扔石头:C++ 异常处理没有普遍的二进制标准。除非您控制用于构建双方的编译器和编译器选项,否则不允许异常在两段代码之间传播;否则,模块可能不支持异常传播的兼容实现。通常,这归结为: 不要让异常跨模块/子系统边界传播。
这是个好问题。C++ 标准不使用模块一词(至少我不这么认为),通常的日常含义类似于翻译单元。除了这不是 Herb 和 Andrei 的意思,因为使用异常的真正目的是从本地代码体中向上传播——否则,您将使用返回码。
我只能猜测,但它们可能意味着可以在不同的 DLL 中合理实现的东西。如果 DLL 是用不同的编译器编译的,或者使用不同的语言,跨 DLL 边界传播异常可能是个问题。否则...
通常认为最佳实践是在 main 中(或在每个线程中的其他一些高级函数中)有一个 try/catch 块,并在那里捕获所有异常,无论它们来自哪里。当你这样做时,现代编译器没有问题。
我没有读过那本书,但听起来它很可能是密歇根大学的这个 pdf 中详细介绍的模块概念。
IE。模块是单个编译单元,通常由头文件和源文件组成。
这在您引用本书的上下文中是有道理的,因为强调了对编译的控制。如果您在单个编译单元(模块)中具有自包含功能,那么您永远不必担心由于依赖特定编译器功能而导致编译功能变得不完整。