取消预处理器定义_取消定义C ++预处理器

最新推荐文章于 2024-07-01 22:34:54 发布

dfsgwe1231

最新推荐文章于 2024-07-01 22:34:54 发布

阅读量940

点赞数

文章标签：编译器 c++ python java 编程语言

原文链接：https://hackernoon.com/undefining-the-c-pre-processor-c4eeb3d06e1f

版权

取消预处理器定义

只有两种语言：人们抱怨的语言和没人使用的语言-Bjarne Stroustrup

我喜欢那句话。它解释了JavaScript和Haskell。通过这种方式，预处理器是一种很棒的语言，因为人们经常使用它。从来没有将它与C和C ++分开考虑，但是如果是这样，它将成为TIOBE上的第一语言。预处理器非常有用且普遍。事实是，要在某种程度上不涉及预处理器的情况下，真的很难编写任何类型的严肃且可移植的C ++应用程序。

—预处理器很烂

- 我知道，对吧？这是最糟糕的。嘿，可以合并我的提交吗？我添加了一堆有用的宏。

我认为很多人都熟悉这种对话，如果我们不小心的话，我们距离现在还有20年的时间。不幸的是，因为现有是预处理器的唯一赎回质量。 my，我的问题既不是理论上的，哲学上的也不是理想主义的。

我根本不在乎预处理器是否允许任何人不用任何检查就替换标识符，关键字（实际上，这是非法的……）。我也不关心预处理器是否在无法正确处理逗号的情况下设法完成图灵处理。我什至不关心包含和包含卫兵，而且#pragma也不是一个问题。有时候你必须要务实。

然而。

让我为您提供一个方案，您可能会发现它是人为的，但请忍受我。因此，想象一下，您正在重构某些跨平台应用程序，并且决定做一些不寻常的事情，例如重命名功能。

那不可能从来没有，也许永远不会。

从根本上讲，无论是编译器还是您的工具（该工具都是成熟的编译器前端）都无法全面了解您的代码。禁用的部分不会被编译，解析，分类或以其他方式进行分析。

首先，禁用的路径没有义务成为有效的C ++。这是有效的：

因此，如果编译器要考虑预处理器的禁用路径，则可能无法获得有效的AST。更糟糕的是，顾名思义，预处理发生在单独的状态，并且预处理指令可能会插入任何两个C ++标记之间，包括在任何表达式或语句的中间。

另一个同样令人担忧的问题是，编译器可能无法知道#ifdef和#defines语句的哪种组合应该构成有效的程序。

例如，Qt提供了一组defines ，这些defines可以设置为在编译时启用或禁用Qt的某些功能。假设您不需要日历小部件，则可以定义#QT_NO_CALENDAR_WIDGET ，这样就可以使用较小的二进制文件。没用我怀疑它永远都行不通。看到，在某个时候，Qt有大约100个这样的编译时配置选项。鉴于构建配置的数量可能随变量的数量呈指数爆炸式增长。当您的程序可能有2´1的变体时，即使在大网络，深云，六进制规模下，自动化也很困难。

未经测试的代码是损坏的代码。

您可能知道那句著名的格言。那什至没有编译代码怎么办？

我应该指出，将某些特定于平台的方法放在特定于平台的文件中会导致完全相同的问题。基本上，编译器看到的代码应该是一个独立的真理源，但是相反，代码是分散的，并且您所拥有的愿景最好是不完整的。

预处理器被认为是有害的，我们该怎么办？

顺便说一句，有缺陷的不仅是预处理器。所有现代处理器显然也是如此。也许应该避免做任何某种处理？

无论如何，让我们今天就可以对预处理器指令进行处理。

`1. Strongly Prefer`常量而不是#define

这个很简单，但是我仍然看到很多使用宏定义的常量。始终使用static const或constexpr而不是define 。如果您的构建过程涉及设置一组变量，例如版本号或git哈希，请考虑生成源文件，而不是使用define作为构建参数。

2.函数总是比宏更好

上面的代码片段来自Win32 API 。即使对于“简单”且短的衬管，您也应该始终偏爱一种功能。

如果需要对函数参数进行延迟求值，请使用lambda。具有讽刺意味的是，这是一个使用宏的解决方案，但这是一个开始！

C ++中函数参数的惰性求值
有时您计算出一个昂贵的参数，然后该函数根本不需要它！ 例如... foonathan.net

3.消除可移植性问题。

在单独的文件，单独的库和方法中正确隔离特定于平台的麻烦，应减少代码中#ifdef块的出现。尽管它不能解决我上面提到的问题，但您不太可能想在不使用该平台的符号的情况下重命名或转换该平台专用的符号。

4.限制软件可以具有的变体数量。

该依赖关系是否真的是可选的？

如果您考虑使用插件系统或将您的项目分成几个项目而具有启用软件某些功能的可选依赖项，那么在缺少依赖项时，将无条件构建组件和应用程序，而不是使用#ifdef禁用某些代码路径。确保在有无依赖项的情况下测试构建。为了避免麻烦，请考虑不要将依赖项设为可选

这段代码真的应该只在发布模式下执行吗？

避免使用许多不同的调试/发布代码路径。请记住，不是已编译的代码是损坏的代码。

该功能真的应该停用吗？

除了依赖之外，功能在编译时也不应是可选的。提供运行时标志或插件系统。

5.首选杂用，包括

如今， #pragma once不支持#pragma once的奇异C ++编译器已经很少了。 #pragma once使用#pragma once不太容易出错，更轻松，更快。亲吻包括卫兵再见。

6.在更多宏中优先使用更多代码

尽管可以适应每种情况，但是在大多数情况下，用宏替换一些c ++标记是不值得的。在语言规则内玩耍，不要尝试过分聪明和容忍重复，它可能具有可读性，可维护性，您的IDE会感谢您。

7.清理宏

应该尽快使用#undef取消宏定义。切勿在头文件中放置未记录的宏。

宏没有作用域，请使用长的大写名称作为项目名称的前缀。

如果您使用的Qt之类的第三方框架同时具有短名称和长宏名称（ signal和QT_SIGNAL ），请确保禁用前者，尤其是当它们可能作为API的一部分泄漏时。不要自己提供这样的简称。宏名称应与其余代码保持一致，并且不得与boost::signal或std::min冲突

8.避免将`ifdef`块放在C ++语句的中间。

foo( 42,
#if 0
  "42",
#endif
 42.0
);

上面的代码有一些问题。它很难阅读，难以维护，并且会导致诸如clang-format工具出现问题。而且，它也碰巧被打破了。

而是编写两个不同的语句：

#if 0
foo(42, "42", 42.0);
#else
foo(42, 42.0);
#endif

您可能会发现很难做到的某些情况，但这可能是您需要将代码拆分为更多功能或更好地抽象出有条件编译的东西的信号。

9.优先使用static_assert而不是#error

只需使用static_assert(false)即可使构建失败。

未来的预处理器

虽然先前的建议适用于任何C ++版本，但是如果您可以访问足够新鲜的编译器，则有越来越多的方法可以帮助您减少日常使用的宏。

1.优先于包括

尽管模块应缩短编译时间，但它们的确提供了宏不能泄漏的障碍。在2018年初，尚无具有该功能的生产就绪编译器，但GCC，MSVC和clang已实现或正在实施中。

虽然缺乏经验，但可以合理地希望模块将使工具变得更容易并且更好地启用功能，例如自动包括与缺少符号相对应的模块，清理不需要的模块……

2.尽可能在#ifdef上使用if constexpr

当禁用的代码路径格式正确（不引用未知符号）时， if constexpr是#ifdef的更好选择，因为禁用的代码路径仍将是AST的一部分，并由编译器和您的工具（包括您的静态分析器和重构程序。

3.即使在后现代世界中，您也可能需要使用#ifdef，因此请考虑使用后现代世界。

尽管它们根本无法解决当前的问题，但仍对一组宏进行了标准化，以检测编译器提供的一组标准功能。如果需要，请使用它们。我的建议是坚持使用您目标中所有编译器提供的功能。选择一个基准线。考虑到将现代编译器回移植到目标系统可能比用C ++ 98编写应用程序要容易。

4.使用std :: source_location而不是LINE和FILE

每个人都喜欢编写自己的记录器。现在，您可以使用std :: source_location使用较少的宏或不使用宏。

走向无宏应用的漫长道路

一些功能为某些宏用法提供了更好的替代方法，但实际上，您仍然必须早于较早使用预处理器。但是幸运的是，我们还有很多事情可以做。

1.用编译器定义的变量替换-D

用于define的最常见用例之一是查询构建环境。调试/发布，目标体系结构，操作系统，优化…

我们可以想象有一组通过std::compiler公开的常量来公开其中一些构建环境变量。

if constexpr(std::compiler.is_debug_build()) {  }

同样，我们可以想象在源代码中声明了某种extern compiler constexpr变量，但编译器定义或覆盖了这些变量。那只会比constexpr x = SOME_DEFINE;具有真正的好处constexpr x = SOME_DEFINE; 是否有办法限制这些变量可以保存的值。

也许像那样

enum class OS {
    Linux,
    Windows,
    MacOsX
};

[[compilation_variable(OS::Linux, OS::Windows, OS::MacOsX)]]  extern constexpr int os;

我的希望是，向编译器提供有关各种配置变量是什么，甚至变量的有效组合的更多信息，将导致对源代码进行更好的建模（以及工具和静态分析）。

2.更多属性

C ++属性很棒，我们应该拥有更多或更多的属性。 [[visibility]]将是一个不错的起点。它可以使用constexpr变量作为从导入切换到导出的参数。

3.从Rust的书中摘录

Rust社区永远不会错过一个机会来大力宣传Rust语言的优点。确实，Rust确实做得很好。而编译时配置就是其中之一。

使用属性系统在编译单元中有条件地包含符号确实是一个非常有趣的想法。

首先，它是真正易读的文档。其次，即使在构建中不包含符号，我们仍然可以尝试对其进行解析，更重要的是，唯一声明为编译器提供了有关实体的足够信息，从而可以进行强大的工具，静态分析和重构。

考虑以下代码：

[[static_if(std::compiler.arch() == "arm")]]
void f() {}


void foo() {
    if constexpr(std::compiler.arch() == "arm") {
        f();
    }
}

它具有惊人的特性：结构良好。因为编译器知道f是有效实体，并且它是函数名称，所以if constexpr语句，它可以明确地分析所丢弃的主体。

您可以将相同的语法应用于任何类型的C ++声明，并且编译器将能够理解它。

[[static_if(std::compiler.arch() == "arm")]]
int x = /*...*/

在这里，编译器只能解析左侧，因为静态分析或工具不需要其余部分。

[[static_if(std::compiler.is_debugbuild())]]
class X {
};

出于静态分析的目的，我们只需要索引类名及其公共成员。

当然，从活动代码路径中引用丢弃的声明会很不正确，但是编译器可以检查该声明对于任何有效的配置都不会发生。当然，它不是免费的计算，但是您将有力保证所有代码的格式正确。因为您是在Linux机器上编写代码而破坏Windows构建的，所以变得更加困难。

但是听起来并不容易。如果废弃实体的主体包含当前编译器不知道的语法怎么办？也许是供应商扩展或某些新的C ++功能？我认为解析是在尽力而为的基础上进行的，并且当解析失败时，编译器可以跳过当前语句并警告其不理解的源代码部分。 “我无法重命名110和130之间的Foo”比“我已重命名Foo的某些实例。也许不是全部，祝您好运手工浏览整个项目，真的不用理会编译器，只需使用grep”即可。

4. constexpr所有东西。

也许我们需要一个constexpr std::chrono::system_clock::now()来代替__TIME__

我们可能还需要编译时随机数生成器。为什么不？谁会关心可复制的构建？

5.通过反射生成代码和符号

自切片面包，模块和概念以来，元类提案是最好的选择。特别是P0712在许多方面都是令人赞叹的论文。

引入的众多构造之一是declname关键字，该关键字可从任意字符串和数字序列创建标识符

int declname("foo", 42) = 0; 创建一个变量foo42 。考虑到字符串连接以形成新标识符是宏的最常见使用案例之一，这确实非常有趣。希望编译器将以这种方式在创建（或引用到）的符号方面获得足够的信息，从而仍可以正确地对其进行索引。

在未来几年，臭名昭著的X macro也将成为过去。

6.要摆脱宏，我们需要一种新型的宏

由于宏只是文本替换，因此它们的参数会被延迟计算。尽管我们可以使用lambda来模仿这种行为，但它相当麻烦。那么，我们可以从函数的惰性评估中受益吗？

这是我去年考虑的话题

cor3ntin / CppInjectionReflection
CppInjectionReflection-C ++ github.com中的代码注入和反射研究

我的想法是使用代码注入提供的功能来创建一种新型的“宏”，由于缺乏更好的名称，我将其称为“语法宏”。从根本上讲，如果给代码片段命名（可以在程序的给定位置注入的一段代码），并允许它接受许多参数，那么您将获得一个宏。但是会在语法级别检查宏（而不是预处理器提供的令牌源）。

它将如何运作？

好的，这是怎么回事。

我们首先使用constexpr { }创建一个constexpr block 。这是元类提案的一部分。 constexpr块是一个复合语句，其中所有变量均为constexpr并且没有副作用。该块的唯一目的是在编译时创建注入片段并修改声明该块的实体的属性。（元类是constexpr块之上的语法糖，我认为我们实际上不需要元类。）

在constexpr块中，我们定义了一个宏log 。请注意，宏不是函数。它们扩展为代码，它们不返回任何内容，也不存在于堆栈中。 log是可以限定的标识符，不能是同一范围内任何其他实体的名称。语法宏与所有其他标识符遵循相同的查找规则。

他们使用->注入运算符。 ->可用于描述所有与代码注入相关的操作，而不会与其当前用法冲突。在您的情况下，由于log是一种语法宏，它是代码注入的一种形式，因此我们使用log->(){....}定义宏。

语法宏的主体本身就是constexpr块，它可以包含可以在constexpr上下文中求值的任何C ++表达式。

它可能包含0个，一个或多个由-> {}表示的注入语句 。注入语句创建一个代码片段，并在调用点立即将其注入，对于语法宏，这是扩展宏的位置。

宏可以插入表达式或0或多个语句。插入表达式的宏只能在期望表达式和倒数表达式之间进行扩展。

尽管没有类型，但它的性质由编译器确定。

您可以将任何参数传递到可以传递给函数的语法宏。在扩展之前对参数进行求值，并进行强类型化。

但是，您也可以在表达式上传递反射。假定能够反映任意表达式。表达式e反射具有与decltype(e)对应的类型。

在实现方面，在上面的示例中， std::meta::expression<char*>是匹配类型为char*的表达式上任何反射的概念。

评估宏时的最后一招是将表达式在扩展之前隐式转换为它们的反射。

从根本上讲，我们正在移动AST节点，这与当前反射和代码注入的方法一致。

最后，当我们注入print(->c, ->(args)...)注意->标记。这样可以将反射转换回原始表达式，然后可以对其进行评估。