在讨论具有大量常量和位模式的项目的设计可能性时，问题出现了关于标准编译器可以处理多少#defines的问题？我认为它是一个非常大的数字，但我们很想知道是否有一个实际的上限。
答案 0 :(得分：8)
对于“标准编译器”：
5.2.4.1：“翻译限制”
实施应该能够 翻译并执行至少一个 包含至少一个的程序 以下每一个的实例 限制
...
同时有4095个宏标识符 在一个预处理中定义 翻译单位
注意表达要求的略微奇怪的方式。实现可以通过拥有一个“黄金程序”来满足它，它们可以识别并编译为特殊情况，尽管这类似于操纵基准测试。在实践中，您可以阅读标准，如果您的实现强加了可用内存以外的限制，那么的限制应至少为4095.超过4095，您在某种程度上依赖于特定于实现的行为
某些编译器（Microsoft）强制实施一些低于标准规定的实施限制。我认为这些列在MSDN的某个地方，但可能只适用于C ++。就C而言，由于我引用了C99，它可能与MSVC无关。
特别是对于GCC和MSVC，测试给定的实现是否施加任意限制应该不会太难，可能比找到文档更容易:-)自动生成只包含很长的{{{{ 1}}，看看预处理器对它们的作用。
答案 1 :(得分：2)
我从来没有听说有人跑了。如初。
答案 2 :(得分：0)
C预处理器在实际使用之前不会展开#define。因此，在典型的实现中，您可能遇到的唯一限制是存储所有这些内存。但是用于存储宏的内部表示的内存基本上最多与编译器读取的文件大小成比例。
（你可以多次包含文件......）
我猜你可以通过扩展深层嵌套的宏来爆炸预处理运行。像
这样的东西#define EXP1(X) X X
#define EXP2(X) EXP1(X) EXP1(X)
#define EXP3(X) EXP2(X) EXP2(X)
.
.
#define EXP64(X) EXP63(X) EXP63(X)
EXP64(A)
应该这样做，因为它会给你2 ^ 64份A，或者左右。 AFAIR，这些宏定义甚至在标准规定的范围内。