可以将不同的 GCC 方言联系在一起吗?
我知道原则上这可能是未定义的行为，但为了处理大型项目，这是我关于 GCC 的问题:
I know that in principle this is probably undefined behaviour, but in the interest of dealing with a large project, here's my question about GCC:
假设我用 gcc -std=c++98 编译一个转换单元，另一个用 -std=c++11 编译，使用完全相同的编译器安装.有什么保证我可以链接两个目标文件并获得一个定义明确的程序吗?
Suppose I compile one transation unit with gcc -std=c++98, and another with -std=c++11, using the exact same compiler installation. Is there any sort of guarantee that I can link the two object files and obtain a well-defined program?
据我所知，由于宏的不同，潜在的问题只能来自库头的不同视图，而那些反过来最多添加新的成员函数，但绝不是成员对象，到标准库类.
As far as I can tell, the potential problems can only come from different views of the library headers due to differing macros, and those in turn would at best add new member functions, but never member objects, to the standard library classes.
这是否会让使用不同语言方言选项编译大型项目的不同部分变得可以接受?
Would this somehow make it acceptable to compile different parts of a larger project with different language dialect options?
更新:我应该添加一个正交问题:使用两个 不同 版本的 GCC(比如 4.3 和 4.6)怎么样，但 相同 方言选项 (-std=c++98)?in this GCC documentation 列表似乎表明该库在4.2.2 和 4.6 之间的两个方向.
Update: I should add an orthogonal question: What about using two different versions of GCC (say 4.3 and 4.6), but wht the same dialect option (-std=c++98)? The listing in this GCC documentation seems to suggest that the library is compatible in both directions between 4.2.2 and 4.6.
推荐答案
先验，没有.最安全的解决方案是假设所有编译器选项都是相同的，除非编译器专门记录该选项不会影响二进制兼容性.(大多数编译器都非常缺乏文档.)实际上，在缺乏文档的情况下，控制警告的选项(g++ 中的 -W...)似乎不会影响二进制兼容性，以及影响代码生成(语言级别等)的选项可能:g++ 通常保持不同优化级别的兼容性，而 VC++ 则没有.
A priori, no. The safest solution is to assume that all of the compiler options are identical, except when the compiler specifically documents that the option doesn't affect binary compatibility. (Documentation which is sorely lacking in most compilers.) In practice, in the lack of documentation, it seems a safe bet that options which control warnings (-W... in g++) won't affect binary compatibility, and that options which affect code generation (language level, etc.) might: g++ generally maintains compatibility across different levels of optimization, where as VC++ doesn't.
另一个真正的问题是在命令行中定义预处理器符号.同样，最安全的选择是所有定义都是相同的，但同样，一些常识是有序的:很难期望标准库已经使用项目中使用的预处理器符号进行编译(例如 MYPROG_CONFIG_FILE_LOCATION，比如说).另一方面，请注意 _GLIBCXX_DEBUG 和 _GLIBCXX_DEBUG_PEDANTIC 的预处理器定义将影响二进制兼容性(尽管 g++ 确保您将获得与它们一起使用的库版本，如果您使用它们始终如一).
Another real problem is defining preprocessor symbols in the command line. Again, the safest bet is that all of the defines be identical, but also again, some common sense is in order: one can hardly expect the standard library to have been compiled with preprocessor symbols which are used in your project (things like MYPROG_CONFIG_FILE_LOCATION, say). On the other hand, be aware that preprocessor definitions of _GLIBCXX_DEBUG and _GLIBCXX_DEBUG_PEDANTIC will affect binary compatibility (although g++ ensures that you will get a library version which works with them if you use them consistently).
关于您的问题:由于标准版本，我预计不会对二进制兼容性产生太大影响，但是如果选择会影响某些预定义的预处理器符号，我不会感到惊讶，在这种方式会破坏库中的二进制兼容性，就像您使用 _GLIBCXX_DEBUG 编译了一些模块一样，而有些则没有.它可能会起作用，但我不会指望它.
With regards to your question: I would not expect to much impact on binary compatibility due to standard version, but it would hardly surprise me if the choice affects some pre-defined preprocessor symbols, in a way that would break binary compatibility in the library, much as if you'd compiled some of the modules with _GLIBCXX_DEBUG, and some without. It might work, but I wouldn't count on it.
相关文章