gpt4 book ai didi

必须仅包含在调试版本中的源文件的条件编译

转载 作者:太空宇宙 更新时间:2023-11-04 05:22:31 24 4
gpt4 key购买 nike

我一直在阅读条件编译的最佳实践,但我还没有找到适合我所遇到情况的示例。

我有一个 C 项目,其目标平台是特定设备(不同于 PC)。我有一个源文件,它只包含用于集成测试和类似功能的功能。我希望此文件仅在 DEBUG 版本中编译和链接,而不是在 RELEASE 版本中编译和链接。

我的问题是以下哪个选项是更好的做法:

*.c 文件如下:

Tests.c
---------
#ifndef NDEBUG
// All testing functions
...
#endif

并将该文件包含在 DEBUGRELEASE 构建中。

或者

检查 NDEBUG 是否从项目的 Makefile/CMakeLists.txt 中定义,并因此包括提到的源文件。

最佳答案

我个人的看法(!):

第一种方法 -- #ifndef NDEBUG -- 更可取。

一开始,有cc *.c .

然后是添加适当的选项。

然后是构建系统,它找出了哪些 *.c文件实际上需要重新编译,并且让您不必记住有哪些合适的选项

然后出现了更复杂的构建系统,它可以为您找出合适的选项。

随着时间的推移,构建系统变得更加智能,并且可以保持重要的逻辑。然而,我觉得这种智能应该继续专注于它们的主要功能(见上文),而且——最终——一个cc *.c。应该仍然在做它的工作。

构建系统会过时或被替换。下一个人可能甚至不知道您选择的构建系统;他应该仍然能够从您的项目中得出结论,而不必深入了解您的构建系统的逻辑。

设置/检查NDEBUG是 C,任何熟悉该语言(和 <assert.h> )的人都会立即认出您打算在那里做什么。

从您的构建系统中弄清楚为什么特定源文件只应包含在特定构建类型中而不应包含在其他构建类型中并不是那么直观,并且当有人站起来扔掉您的 CMakeLists.txt 时可能会完全丢失退出,因为他更喜欢 Jam 并从头开始构建它。那个人可能最终会想知道为什么所有这些测试都会弄乱他的发布代码,以及为什么你不够聪明,不能让它们只用于调试(没有意识到你确实在你的构建系统中这样做了) .

关于必须仅包含在调试版本中的源文件的条件编译,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56423142/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com