让宏定义返回函数的值是不好的做法吗？

Question

使用定义的宏来有条件地返回一个值有一个缺点，即仅查看客户端代码并不明显，可能会在宏点退出。

我正在考虑的用例是编写值和错误检查，如下所示：

#define WRITE_CHK(file, param)\
if (!write_that_returns_zero_on_fail(file, param)) {\
   handle_error();\
   return false;\
}

客户端代码：

bool myfunc()
{
   ...
   WRITE_CHK(file, param) // function might return here
   ...
   return true;
}

我很好奇宏（将在我的代码中的许多地方使用）的好处是否会超过上面提到的缺点。 除了简单扩展（不使用宏）之外，还有其他首选方法吗？

Answer 1

标准答案是“不要使用宏”；但这通常有点简单化。在某些情况下，它们可以大大减少您原本应该拥有的样板冗长。

那么，为什么不将事实编码到宏名称中呢？例如WRITE_OR_RETURN_ON_FAILURE。它可能有点冗长，但不太可能绊倒您的代码读者。

Answer 2

在宏中隐藏控制流并不常用，因此可能会让必须理解或调试代码的开发人员感到困惑。

我建议不要完全使用宏，但如果必须使用它们，请确保控制流部分是明确的。

// assume handle_error returns true
#define WRITE_FAILED(file, param)\
(!write_that_returns_zero_on_fail(file, param) && handle_error())

// macro usage
if(WRITE_FAILED(file, param))
{
    return;
}

要问自己的另一个问题是——为什么还要在这里使用宏？如果要隐藏控制流，那不是一个好主意。还有其他原因吗？

Answer 3

制作一个两步宏：

#define WRITE_CHK_(file, param, HANDLER)\
if (!write_that_returns_zero_on_fail(file, param)) {\
    handle_error();\
    HANDLER\
}

#define RFALSE return false;

#define WRITE_CHK(file, param) WRITE_CHK_(file, param, RFALSE)

如果您需要在其他地方进行类似检查，则可以制作其他包装器（或直接使用WRITE_CHK(file, param, return false)）

Answer 4

是的，这很糟糕。使用goto。

 #define fail_unless(x) do {if(!(x)) goto fail;} while (0)

 int foo()
 {
     fail_unless( my_write(...) );
     fail_unless( bar() );
     return 0;
 fail:
     cleanup();
     return -1;
 }

编辑：如果您因为不了解 while 循环在那里做什么而投反对票，那么您应该问一下。这是确保 C 宏在任何上下文中都充当单个语句的标准技术。如果您的宏扩展为 if 语句（就像其他被赞成的答案中的宏），那么您会得到意想不到的副作用，例如：

 #define DONT_DO_THIS(x) if (!x) { foo; }

 if (a) DONT_DO_THIS(x)
 else something_else();

你希望something_else 在!a 时被执行，但宏实际上扩展为：

 if (a)
     if (!x) { foo;}
     else something_else();

something_else 在a && x 时执行，而不是在!a 时按照程序员的意图执行。