有时在编码竞赛中，我会看到像
这样的内容#define FOR(a,b,c) for (i64(a)=(b);(a)<(i64)(c);(a)++)
这被认为是好的/不好的做法，还有其他任何影响（性能，稳定性 - 什么？）。
基本上，如果键入FOR(a,b,c)“更短”，为什么不总是这样做？
答案 0 :(得分：2)
在运行时，它不应该比完全写出的版本更糟糕。这是因为预处理器宏在编译之前会被扩展，所以它对编译器看到的内容没有影响。
反对它的主要论点可能是可读性。你必须确切地知道FOR将要扩展到什么，并确保它符合你的期望。对于一次性项目或原型，这可能不是问题。在更大或更长期的项目中，您可能会发现它成为一种负担，尤其是当您尝试调试循环时。
答案 1 :(得分：0)
效率不高。它确保每次都以同样的方式完成同样的事情。通常会使用一个函数，但宏可能会保存函数调用，在某些情况下，这会更有效。
为什么不总是使用宏？因为你可能并不总是需要i64强制转换，这就是for循环作为一般构造的原因。
答案 2 :(得分：0)
我个人避免使用宏，除非我真的离不开它们。
来自 Google C ++风格指南
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Preprocessor_Macros：
宏意味着您看到的代码与编译器看到的代码不同。这可能会引入意外行为，尤其是因为宏具有全局范围。
答案 3 :(得分：0)
在编码竞赛中，人们会使用书中的每一个技巧来减少事情。
这是不错的做法。
我认为不是出于简单的原因 - 维护。
另外，恕我直言的宏是一个非常糟糕的主意。