Tag: 编译时

C预处理器能够通过char处理字符串char吗？

我想在编译时隐藏字符串。 我知道它可以在其他预处理器中完成，但我还没有找到一种方法来使用C预处理器。

C可以在编译时排序吗？

是否可以在C中编译时对元素进行排序？ 语法是次要的，我正在考虑这样的宏： SORT(9, -1, 12, 4) // expands to: -1, 4, 9, 12 SORT(dog, cat, cow) // expands to: cat, cow, dog 但是我不会对任何API皱眉，只要它排序而不发出单个CPU指令。 要求非常宽松： 纯C，没有C ++ 。 保持在C标准内会很好，但已建立的语言扩展是公平的游戏。 编译器是唯一允许的工具 。 Unix sort或自制代码生成器不受欢迎，因为它们使构建步骤复杂化。 任何元素类型都可以 。 如果它可以排序例如数字而不是字符串，那就没关系。 固定长度的API很好 。 必须调用SORT_5来排序5个元素SORT_5 。 我意识到解决方案可能会使用一些几乎没有编译的语言巫术，我只是想知道它是否可能。

编译时大小有条件

如果涉及sizeof的条件为true，我想定义一个宏，如果它为false，则不执行任何操作（但仍然编译）。 如果预处理器支持sizeof ，它将如下所示： #if (sizeof(void*) <= sizeof(unsigned int)) // what goes here? # define POINTER_FITS_INTO_UINT #endif 有一些页面（例如http://scaryreasoner.wordpress.com/2009/02/28/checking-sizeof-at-compile-time/ ）解释了如何在sizeof上进行编译时断言 （并且无法编译）如果它失败了），但我没有看到将这种方法扩展到我想要的方法。

如何在编译时确定数组的长度？

是否有可以在GCC编译时返回数组长度的宏或内置函数？ 例如： int array[10]; 对于： sizeof(array) == 40 ???(array) == 10 Update0 我可能只是指出在C ++中这样做是微不足道的。 可以构建一个返回[]内部数字的模板。 我确信我曾经在Visual C ++编译器中找到了一个dimof和dimof宏/内置，但是再也找不到它了。

“未定义的行为”是否延伸到编译时？

我们都听过警告，如果你在C或C ++中调用未定义的行为 ， 任何事情都可能发生。 这是否仅限于任何运行时行为 ，还是包含任何编译时行为？ 特别是，编译器在遇到调用未定义行为的构造时，允许拒绝代码（在标准中没有其他要求的情况下这样做），甚至崩溃？

如何在C中编译时打印sizeof（）的结果？

如何在C中编译时打印sizeof（）的结果？ 现在我使用静态断言（基于其他Web资源自制）来将sizeof（）结果与各种常量进行比较。 虽然这有效但它远非优雅或快速。 我还可以创建变量/ struct的实例并查看映射文件，但这也比直接调用/命令/运算符更不优雅和快速。 此外，这是一个使用多个交叉编译器的嵌入式项目……因此，为目标构建和加载示例程序然后读出一个值比上述任何一个都更麻烦。 在我的情况下（旧的GCC）， #warning sizeof(MyStruct) ）在打印警告之前实际上并不解释sizeof（）。

常量表达式的数学函数是否在编译时预先计算？

我倾向于使用常量表达式的数学函数来获得方便性和连贯性（即log(x)/log(2)而不是log(x)/0.3… ）。 由于这些函数实际上并不是语言本身的一部分，因此它们都没有在math.h定义（仅声明），是否会在编译时预先计算常量函数，还是在运行时浪费计算？

检测字节序

我正在尝试创建一个C源代码，无论目标系统的字节顺序如何，它都能正确处理I / O. 我选择了“little endian”作为我的I / O约定，这意味着，对于大端CPU，我需要在写入或读取时转换数据。 转换不是问题。 我面临的问题是检测字节序，最好是在编译时（因为CPU在执行过程中不会改变字节序…）。 到目前为止，我一直在使用这个： #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ … #else … #endif 它被记录为GCC预定义宏，Visual似乎也理解它。 但是，我收到报告说某些big_endian系统（PowerPC）的检查失败了。 所以，我正在寻找一个万无一失的解决方案，确保无论编译器和目标系统如何都能正确检测到字节顺序。 好吧，他们中的大多数至少…… [编辑]：提出的大多数解决方案都依赖于“运行时测试”。 编译期间编译器有时可以正确评估这些测试，因此不会产生实际的运行时性能。 但是，使用某种<< if (0) { … } else { … } >>进行分支是不够的。 在当前的代码实现中，变量和函数声明依赖于big_endian检测。 使用if语句无法更改这些内容。 嗯，显然，有后备计划，即重写代码…… 我宁愿避免这种情况，但是，它看起来像是一个越来越小的希望…… [编辑2]：我通过深度修改代码测试了“运行时测试”。 尽管他们正确地完成了工作，但这些测试也会影响性能。 我期待着，因为测试具有可预测的输出，编译器可以消除坏分支。 但不幸的是，它并不是一直有效。 MSVC是一个很好的编译器，并且成功地消除了坏分支，但GCC的结果好坏，具体取决于版本，测试类型，以及对64位比对32位的影响更大。 真奇怪。 并且这也意味着无法确保编译器处理运行时测试。 编辑3 ：这些天，我正在使用编译时常量联合，期望编译器将其解析为明确的是/否信号。 它运作得很好： https ： //godbolt.org/g/DAafKo