将析构函数中的关键函数放置到 "enhance atomicity"？
Place critical functions in destructor to "enhance atomicity"?
假设我有两个 C++ 函数 foo1() 和 foo2()，我想尽量减少 foo1() 开始执行但 foo2() 由于某些外部事件而未被调用的可能性。我不介意两者都没有被调用，但是如果调用了 foo1() 则 foo2() 必须执行。两个函数都可以连续调用，不会抛出异常。
将函数包装在对象中并在析构函数中调用它们有什么好处/缺点吗？如果应用程序是多线程的（比如父线程崩溃），情况会发生变化吗？是否有任何其他选项可确保只要调用 foo1() 就调用 foo2()？
我认为将它们放在析构函数中可能有助于例如SIGINT，虽然我知道 SIGINT 会立即停止执行，即使在析构函数的中间。
编辑：
澄清一下：foo1() 和 foo2() 都将被抽象掉，所以我不担心其他人以错误的顺序调用它们。我的担心仅与应用程序执行期间的崩溃、异常或其他中断有关（例如有人按下 SIGINT、另一个线程崩溃等）。
如果另一个线程崩溃（没有相关的信号处理程序 -> 整个应用程序退出），您无法保证您的应用程序执行某些操作 - 这取决于 OS 所做的。并且总是有系统会在您实际不知情的情况下终止您的应用程序的情况（例如导致 "all" 内存被您的应用程序使用以及 OS "out of memory killer" 终止您的进程的错误）。
唯一保证执行析构函数的情况是构造对象并抛出 C++ 异常。所有信号等等，都没有做出这样的保证，并且在例如 SIGSEGV 或 SIGBUS 很好地进入世界的 "undefined" 部分之后继续 [在同一线程中] 执行 - 你无能为力，因为SEGV 通常表示 "you tried to do something to memory that doesn't exist [or that you can't access in the way you tried, e.g. write to code-memory]"，处理器会中止当前指令。尝试从原来的地方继续，要么导致再次执行相同的指令，要么跳过该指令 [如果您继续执行下一条指令——我暂时忽略了确定它在哪里的麻烦]。当然，有些情况下 IMPOSSIBLE 可以继续，即使你想继续 - 例如堆栈指针已损坏 [从被覆盖的内存中恢复等]。
简而言之，不要花太多时间尝试想出一些可以避免此类情况的方法，因为它不太可能奏效。花时间尝试提出不需要知道是否完成某事的方案 [例如基于事务的编程，或 "commit-based" 编程（不确定这是不是正确的术语，但基本上你知道一些步骤，然后 "commit" 到目前为止完成的事情，然后再做一些进一步的步骤，等等 - 只有已经 "committed" 的事情肯定会完成，下一次将丢弃未提交的工作），某件事要么完全完成，要么完全丢弃，具体取决于它是否完成。
将应用程序的 "sensitive" 和 "not sensitive" 部分分离到单独的进程中可能是另一种提高安全性的方法。
假设我有两个 C++ 函数 foo1() 和 foo2()，我想尽量减少 foo1() 开始执行但 foo2() 由于某些外部事件而未被调用的可能性。我不介意两者都没有被调用，但是如果调用了 foo1() 则 foo2() 必须执行。两个函数都可以连续调用，不会抛出异常。
将函数包装在对象中并在析构函数中调用它们有什么好处/缺点吗？如果应用程序是多线程的（比如父线程崩溃），情况会发生变化吗？是否有任何其他选项可确保只要调用 foo1() 就调用 foo2()？
我认为将它们放在析构函数中可能有助于例如SIGINT，虽然我知道 SIGINT 会立即停止执行，即使在析构函数的中间。
编辑：
澄清一下：foo1() 和 foo2() 都将被抽象掉，所以我不担心其他人以错误的顺序调用它们。我的担心仅与应用程序执行期间的崩溃、异常或其他中断有关（例如有人按下 SIGINT、另一个线程崩溃等）。
如果另一个线程崩溃（没有相关的信号处理程序 -> 整个应用程序退出），您无法保证您的应用程序执行某些操作 - 这取决于 OS 所做的。并且总是有系统会在您实际不知情的情况下终止您的应用程序的情况（例如导致 "all" 内存被您的应用程序使用以及 OS "out of memory killer" 终止您的进程的错误）。
唯一保证执行析构函数的情况是构造对象并抛出 C++ 异常。所有信号等等，都没有做出这样的保证，并且在例如 SIGSEGV 或 SIGBUS 很好地进入世界的 "undefined" 部分之后继续 [在同一线程中] 执行 - 你无能为力，因为SEGV 通常表示 "you tried to do something to memory that doesn't exist [or that you can't access in the way you tried, e.g. write to code-memory]"，处理器会中止当前指令。尝试从原来的地方继续，要么导致再次执行相同的指令，要么跳过该指令 [如果您继续执行下一条指令——我暂时忽略了确定它在哪里的麻烦]。当然，有些情况下 IMPOSSIBLE 可以继续，即使你想继续 - 例如堆栈指针已损坏 [从被覆盖的内存中恢复等]。
简而言之，不要花太多时间尝试想出一些可以避免此类情况的方法，因为它不太可能奏效。花时间尝试提出不需要知道是否完成某事的方案 [例如基于事务的编程，或 "commit-based" 编程（不确定这是不是正确的术语，但基本上你知道一些步骤，然后 "commit" 到目前为止完成的事情，然后再做一些进一步的步骤，等等 - 只有已经 "committed" 的事情肯定会完成，下一次将丢弃未提交的工作），某件事要么完全完成，要么完全丢弃，具体取决于它是否完成。
将应用程序的 "sensitive" 和 "not sensitive" 部分分离到单独的进程中可能是另一种提高安全性的方法。