Exception 当异常被禁用时，使用锁（而不是裸互斥）对条件变量有意义吗？

这个问题的答案很好地解释了在C++11（或Boost）中使用锁而不是裸互斥体作为条件变量背后的原理

我正在为深度嵌入式目标设计一个RTOS，这主要是因为内存限制（这些微控制器通常有128kB-1MB范围的ROM和16-128kB范围的RAM）意味着可以毫无例外地使用

*

。这就是为什么我没有在互斥函数（或任何其他函数）中抛出异常，而是返回错误代码，就像POSIX pthread一样。在这样的设计中，从C++11实现类似于

unique\u lock

的东西仍然很简单，但我觉得这有点错误。。。当您有异常时，无法使用

unique\u lock

锁定互斥锁，因为将引发异常。当您没有异常时，您可以在发生故障时调用

abort（）

，或者将最后一个错误代码保留在锁中，并提供一个访问器来获取它（无法很好地、轻松地从构造函数返回错误）-我觉得这两种解决方案都是“错误的”，我想不出更好的方法了。。。这就是为什么现在我的条件变量实现使用裸互斥体（如POSIX pthread函数），并且没有实现与

unique\u lock

等效的方法

另一方面，我不排除有人实际使用异常时的用例，但这些用例将是规则的“例外”

我的问题是，我无法想出一个对这两种情况都有好处的解决方案（无论是否有例外）

那么，当使用错误代码而不是异常编写代码时，实现与

unique\u lock

等效的锁，并将其与条件变量而不是裸互斥体一起使用，这有意义吗？是否有任何非难看的解决方案来创建一个

唯一的\u锁

，该锁将使用返回错误代码而不是抛出的互斥锁？我真的觉得调用

abort（）

（或断言）是非常错误的，因为它让用户没有机会处理错误。。。使用RAII语义从对象返回错误代码也是非常错误的。当使用工厂方法（拉入动态分配或使用类似

std:：optional

）时，它可能会工作，但是如果是简单的错误代码，这个功能（

unique\u lock

）值得所有的麻烦吗

---

---

*

-尽管流行的流行语是“你不用为你不用的东西付费”，但实际上不可能轻易地在GCC中完全禁用异常。如果使用-fno exceptions标志，则会禁用代码的异常，但库中用于处理异常的代码仍然存在，因此可以调用

new

，创建

字符串

，或者创建

向量

，并且处理异常的代码仍然包含在内。对于桌面环境来说，这可能没有什么不同，但对于一个您将不使用的功能（可以通过覆盖

verbose\u terminate\u handler（）

进行限制，但仍然留下很多）的深入嵌入，这几十千字节的代码会产生不同。为了完全禁用异常，我重新编译了ARM微控制器的整个工具链，将-fno异常传递到编译标准库本身的过程中-只有在删除此功能后才可以使用。

选择您愿意支持的目标语言。从C或C++中选取。任何类型的“C++，但不是真正的”不会做任何事情，而是造成痛苦。@汉斯潘-使用C++并不意味着你必须使用异常（或任何其他的特征）。