我不是c++程序员，所以我不会在这里写任何代码，但到目前为止还没有人提到面向对象的解决方案。下面是我的猜测:

拥有一个通用接口，该接口提供了一个方法来评估单个条件。现在，您可以在包含有问题的方法的对象中使用这些条件的实现列表。遍历列表并计算每个条件，如果其中一个条件失败，可能会提前爆发。

这样的设计很好地遵循了开/闭原则，因为在初始化包含相关方法的对象时，可以很容易地添加新的条件。您甚至可以向接口添加第二个方法，该方法用于条件评估，返回条件的描述。这可以用于自文档系统。

但是，缺点是由于使用了更多的对象和遍历列表，所涉及的开销稍微多一些。

当然不是答案，而是一个答案(为了完整起见)

而不是:

do {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
} while(0);

你可以这样写:

switch (0) {
case 0:
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
}

这仍然是一个伪装的goto，但至少它不再是一个循环。这意味着你不需要非常仔细地检查是否有一些继续隐藏在块的某处。

构造也非常简单，您可以希望编译器会优化它。

正如@jamesdlin所建议的，你甚至可以把它隐藏在一个宏后面

#define BLOC switch(0) case 0:

然后像这样使用它

BLOC {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
}

这是可能的，因为C语言语法期望在开关之后有一个语句，而不是一个括号中的块，并且您可以在该语句之前放置一个case标签。到目前为止，我还没有看到允许这样做的意义，但在这种特殊情况下，将开关隐藏在一个漂亮的宏后面是很方便的。

从函数式编程的角度来看，这是一个众所周知的、很好解决的问题——也许是单子。

为了回应下面我收到的评论，我在这里编辑了我的介绍:你可以在不同的地方找到实现c++单子的完整细节，这将让你实现Rotsor建议的目标。这需要一段时间来理解单子，所以我要在这里建议一个快速的“穷人”单子式机制，你只需要知道boost::optional。

设置你的计算步骤如下:

boost::optional<EnabledContext> enabled(boost::optional<Context> context);
boost::optional<EnergisedContext> energised(boost::optional<EnabledContext> context);

显然，每个计算步骤都可以执行类似于返回boost::none这样的操作，如果给出的可选参数为空的话。例如:

struct Context { std::string coordinates_filename; /* ... */ };

struct EnabledContext { int x; int y; int z; /* ... */ };

boost::optional<EnabledContext> enabled(boost::optional<Context> c) {
   if (!c) return boost::none; // this line becomes implicit if going the whole hog with monads
   if (!exists((*c).coordinates_filename)) return boost::none; // return none when any error is encountered.
   EnabledContext ec;
   std::ifstream file_in((*c).coordinates_filename.c_str());
   file_in >> ec.x >> ec.y >> ec.z;
   return boost::optional<EnabledContext>(ec); // All ok. Return non-empty value.
}

然后把它们串在一起:

Context context("planet_surface.txt", ...); // Close over all needed bits and pieces

boost::optional<EnergisedContext> result(energised(enabled(context)));
if (result) { // A single level "if" statement
    // do work on *result
} else {
    // error
}

这样做的好处是，您可以为每个计算步骤编写定义清晰的单元测试。此外，调用读起来像简单的英语(通常是函数式风格的情况)。

如果你不关心不可变性，并且每次返回相同的对象更方便，你可以使用shared_ptr或类似的方法来提出一些变化。

Try to extract the code into a separate function (or perhaps more than one). Then return from the function if the check fails. If it's too tightly coupled with the surrounding code to do that, and you can't find a way to reduce the coupling, look at the code after this block. Presumably, it cleans up some resources used by the function. Try to manage these resources using an RAII object; then replace each dodgy break with return (or throw, if that's more appropriate) and let the object's destructor clean up for you. If the program flow is (necessarily) so squiggly that you really need a goto, then use that rather than giving it a weird disguise. If you have coding rules that blindly forbid goto, and you really can't simplify the program flow, then you'll probably have to disguise it with your do hack.

在函数中隔离这些决策并使用返回而不是中断被认为是可以接受的实践。虽然所有这些检查都对应于与函数相同的抽象级别，但这是一种非常符合逻辑的方法。

例如:

void foo(...)
{
   if (!condition)
   {
      return;
   }
   ...
   if (!other condition)
   {
      return;
   }
   ...
   if (!another condition)
   {
      return;
   }
   ... 
   if (!yet another condition)
   {
      return;
   }
   ...
   // Some unconditional stuff       
}

也许就像这样

#define EVER ;;

for(EVER)
{
    if(!check()) break;
}

或者使用异常

try
{
    for(;;)
        if(!check()) throw 1;
}
catch()
{
}

使用异常还可以传递数据。