是“make install”吗？被认为有害？
根据这篇文章，Google C++ 测试框架认为“make install”是一种不好的做法。
http://groups.google.com/group/googletestframework/browse_thread/thread/668eff1cebf5309d
原因是这个库违反了“单一定义规则”。
http://en.wikipedia.org/wiki/One_Definition_Rule
在线程的更远的地方它说： “如果将不同的 -DGTEST_HAS_FOO=1 标志传递给不同的翻译单元，则会违反 ODR。或者有时人们会使用 -D 选择要使用的 malloc 库（调试与发布），并且您有 全面使用相同的 malloc 库。”
我的问题：
- 这个项目到底做错了什么？
- 我们可以从中学到什么？我们如何编写更具防御性的代码来防止违反 ODR？
According to this post the Google C++ Testing Framework considers "make install" a bad practice.
http://groups.google.com/group/googletestframework/browse_thread/thread/668eff1cebf5309d
The reason for this is that this library violates the "One Definition Rule".
http://en.wikipedia.org/wiki/One_Definition_Rule
Somewhere further in the thread it says: "If you pass different -DGTEST_HAS_FOO=1 flags to different translation units, you'll violate the ODR. Or sometimes people use -D
to select which malloc library to use (debug vs release), and you have
to use the same malloc library across the board."
My questions:
- What is it exactly this project is doing wrong?
- What can we learn from this? How can we write code more defensive to prevent violating the ODR?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这个问题的直接答案是：不要编写依赖于编译器参数的代码。在这种情况下，整个讨论源于这样一个事实：代码根据编译器标志而不同（最有可能通过#ifdef或其他预处理器指令）。这反过来意味着，虽然代码库相同，但通过更改编译器标志，处理的代码将会不同，并且使用一组标志编译的二进制文件将与使用不同标志编译的二进制文件不兼容一组标志。
根据实际项目，可能无法将代码与编译器标志解耦，您将不得不忍受它，但我建议尽可能避免使用可以配置的代码编译器命令行，就像您应该避免仅调试具有副作用的代码一样。如果您做不到，请记录不同编译器标志的效果。
The straight answer to the question would be: do not write code that depends on compiler parameters. In this case, the whole discussion stems from the fact that the code is different based on compiler flags (most probably by means of
#ifdefor other preprocessor directives). That in turn means that while the codebase is the same, by changing compiler flags the processed code will be different, and a binary compiled with one set of flags will not be compatible with a binary compiled with a different set of flags.Depending on the actual project, it might be impossible to decouple the code from compiler flags, and you will have to live with it, but I would recommend avoiding in as much as possible code that can be configured from the compiler command line, in the same way that you should avoid DEBUG only code with side effects. And when you cannot, document the effect that different compiler flags have.