|
|
1
1
我想现在的主要问题是,你现在是在测试你的代码还是编译器? 测试编译器不一定是件坏事。。。我在过去遇到过编译器升级掩码错误,因此最好确保您得到与预期相同的安全检查集。
一个稍微简单一点的方法可能是保留一个坏代码目录,让脚本一次编译一个文件。在那里有一个“#ifdef MAKEFAIL”标志,用于打开应该失败的确切条件。确保编译器在未设置该标志时返回0,在设置该标志时返回非零。假设编译器在失败时返回非零。。。我不知道MSVC是否遵循这个规则。 为了解决可移植性问题,我将抛出的第三个选项是autoconf。设置起来可能很痛苦,但其部分目的是确保在编译之前拥有一个健全的开发环境。您可以在其中添加一个这样的测试,它可以让您找到编译器并进行尝试。 |
|
|
2
1
这似乎有点像在*nix机器上从源代码对构建进行“/configure”时发生的自动检测。autoconf脚本构建小程序并尝试编译它们,以确定编译器支持的可用程序。 重用其中的任何一个可能都不实际,但您可能需要相同的模型。每个测试都有自己的文件或一组文件,以及一个单独的项目文件/maketarget/等。。然后,您的测试脚本将尝试生成每个测试用例,并通过grep或将输出与存储在测试用例中的基线输出进行比较,检查是否发生了预期的错误。 |
|
|
3
0
但是在这种情况下,您真正需要的是一个静态分析工具,它检查以确保您的开发人员编写的代码遵循这样的约定。这当然是一个有效的构建工具。但是,搜索静态分析工具来查找您在这里指定的内容可能很困难。我从维基百科的文章开始 List of tools for static code analysis ,在 C/C++ 节。 请注意,您编写的代码不是“错误”,它只是您的约定。这是一个非常好的约定,但编译器不应该也不应该约束您遵守该约定。静态分析工具也不应如此。因此,您需要找到一个允许您配置什么是允许的,什么是不允许的。 |
|
|
4
0
|
|
Fahim B · 删除id号之间的空格[重复] 1 年前 |
|
|
Matt Schaaf · 如何获得每15分钟生成的数据点的日均值? 2 年前 |