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

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

是的，这很糟糕。 Use a 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;
 }

Edit: if you're downvoting because you don't understand what that while loop is doing there, you should just have asked. It is a standard technique for making sure a C macro acts as a single statement in any context. If your macro expands to an if statement (like the macros in the other, upvoted answers), then you get unexpected side effects, eg:

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

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

You'd expect something_else to be executed when !a, but what the macro actually expands to is:

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

And something_else is executed when a && x, not when !a as the programmer intended.