Question

如果它们提高了代码可读性，那么定义类似关键字的宏是不对的吗？

例如，IMPLICIT宏：

#define IMPLICIT /* IMPLICIT constructor(parameters...); */

struct X
{
    explicit X();
    IMPLICIT X(int i);
    IMPLICIT X(std::sting s);
    explicit X(const char* ch);
};

而不是：

struct X
{
    explicit X();
    X(int i);
    X(std::sting s);
    explicit X(const char* ch);
};

考虑因素：无论代码可读性如何，IMPLICIT宏的定义都可以更改为简单地禁用所有隐式构造函数或...，以便将来维护。

编辑：我的示例并不重要，我的问题并不具体，我删除了block宏示例。

Answer 1

定义类似关键字的宏只是为了提高代码的可读性

我认为这是可以接受的。但就像马可说的那样，它相当主观。

我认为宏增强可读性的一个例子是C ++和NOTHROW。奇怪的是，指定throw()表示函数不会抛出;并且反对throw (SomeException)，这意味着函数可能抛出异常。

Stack Overflow上有很多关于它的讨论：

Microsoft定义throw()，IN和OUT以帮助提高可读性和可用性。宏装饰函数参数并没有定义。例如，您可能会看到（我没有特定的Microsoft示例）：

INOUT

相关：宏有助于抽象平台差异。例如，从共享对象（Unix和仿冒品）或动态链接库（Windows）导出函数。

相关：宏有助于抽象配置差异。例如，调试和发布配置中// Process foo. Reuse baz if possible; reallocate if needed and return size. // Return TRUE/FALSE as success/failure. Return an error code if result is FALSE. int FooBarBaz(IN char* foo, IN int flen, INOUT char** baz, INOUT int* blen, OUT int* err);的含义或实现。

相关：劫持关键字可能会有所帮助。例如，在测试期间将C ++的ASSERT和protected重新定义为private可能会有所帮助，因此可以针对不具有的方法编写测试用例。通常可以访问。

Answer 2

如上所述，您的宏不会增强可读性。有人可能想知道BLOCK或IMPLICIT是什么意思，认为他们执行某些特殊功能，而事实上他们没有。它似乎更适合评论或重构。在像Visual Studio这样的IDE中，您可以折叠代码行（隐藏/显示它们）或将它们分组到文档块（即#REGION）中。不做任何事情的宏只会给你的代码增加噪音。

Answer 3

我最好的宏是一个记录宏：

#define SYSTEM_FAILURE(code, comment) \
{ \
    System_Failure(code, comment, __FILE__, __FUNCTION__, __LINE__); \
}

宏是插入遇到故障的文件名，函数名和行号的最简单方法。

除了这个宏，我们的商店里没有。

Answer 4

很难找到好的例子，用于提高可读性的宏是无法避免的。

这是我能想到的最好的例子（来自Linux内核）：

#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))

示例：

struct book {
  char title[100];
  char author[100];
};

// ...
printf("%lu\n", FIELD_SIZEOF(struct book, title)); // prints 100

（我不知道在C ++中是否可以避免使用这个宏。）

除此之外，我认为当宏用于代码生成以消除样板代码时，宏有时可以提高可读性。

定义类似关键字的宏只是为了提高代码的可读性

4 个答案: