每当我使用Visual C ++ 9编译SQLite时,我都会收到数百条警告,例如
我并不孤单 - 有一个SQLite FAQ question专门针对这一点。该问题的答案是
当然,我不能反对这些观点,但是......
这就是为什么我不喜欢简单地忽略所有警告的想法。
那么我如何处理编译SQLite时VC ++显示的警告?
答案 0 :(得分:1)
为什么不使用#pragmas
来禁用这些警告,如果它们实际上没有造成任何伤害?或者切换到较低的警告级别(因为我假设您将SQLite源作为单独的VC lib项目?)
答案 1 :(得分:0)
任何使用C ++的开发人员如何处理警告?调查您收到警告的代码,确定警告是否告诉您需要知道的事项,然后根据需要更改代码。我不确定我真的理解你的问题。
也许如果你发布了一个特定的警告(带代码),我们可能会告诉你你需要做些什么。
答案 2 :(得分:0)
我想说编译像SQLite一样复杂的东西,使用编译器和开发人员自己说永远不会使用的库,注定要失败,或者至少会非常非常痛苦。 GCC易于在Windows上安装和使用(从http://tdragon.net/recentgcc获取),为什么不使用它呢?
答案 3 :(得分:0)
首先,请记住警告不是错误指示符。他们在那里吸引开发人员注意可能指示错误的事情,而不是别的什么。
如果代码有效,则发出的警告数量几乎无关紧要。
如果你想安全地玩它,请查看警告:它们中的任何一个是否与VS和GCC以不同方式处理的实现定义的行为有关?如果是这样,您可能会遇到问题。但只要警告是关于两个编译器处理相同的事情(例如整数/双转换),就可以忽略它。
我记得(自从我在VS上编译SQLite而没有静默警告)已经有一段时间了,几乎所有的警告都是关于内置类型之间的隐式转换,只要开发人员知道它们,所有这些都是非常安全的发生了。
SQLite在VS上运行得很好。该库被许多大型项目广泛使用。它经过了相当广泛的测试。
答案 4 :(得分:0)
在VC9解决方案资源管理器中选择文件,右键单击,选择“属性”。
然后转到C++
- > General
标签,并将Warning level
设置为Off
。
这将仅关闭这些文件的所有警告。
我使用我使用的大多数外部lib文件:没有任何好处来“修复”那些(如果它们不是真正的错误),关闭警告有助于保持构建输出窗口清洁,所以我不喜欢在我自己的代码中错过了警告。
答案 5 :(得分:0)
这些警告基本上意味着:
如果将代码移植到一个环境中,其中所有基本类型(char,short,int,long,long long)与原始开发人员使用和测试的大小完全相同,代码可能会按测试工作(虽然注意那些可能未初始化的变量),但
如果您将代码移植到某些基本类型与原始开发人员使用的大小不同的环境中,您很可能会以某种神秘且反直觉的方式破解代码。您收到这些警告的地方。即使您在两种环境中都使用GCC,情况也是如此。有关可能发生的行为的一些示例,请参阅C FAQ 3.19(请记住,C和C ++标准现在都要求“保留价值”规则)。
这是编码草率的一个标志。他们真的应该解决导致这些警告的大多数问题(通常,在二元运算符中混合有符号和无符号类型是有风险的,我敢打赌他们在这里做了很多)。我修复了过去导致此类警告的其他人的代码,使其更适合移植到未来的环境中。但是,如果他们正在编译和测试你将使用相同的基本类型大小(他们几乎肯定是如果有一个兼容的C语言接口链接到),那么你可能可以逃脱而不修复许多这些问题。