¿Pueden los diferentes dialectos de GCC vincularse?

Sé que, en principio, este es probablemente un comportamiento indefinido, pero en el interés de tratar con un gran proyecto, esta es mi pregunta sobre GCC:

Supongamos que compilo una unidad de transacción con gcc -std=c++98 y otra con -std=c++11 , utilizando exactamente la misma instalación del comstackdor. ¿Hay algún tipo de garantía de que puedo vincular los dos archivos objeto y obtener un progtwig bien definido?

Por lo que puedo decir, los problemas potenciales solo pueden provenir de diferentes vistas de los encabezados de las bibliotecas debido a las diferentes macros, y estos a su vez agregarían nuevas funciones miembro, pero nunca objetos miembros, a las clases de biblioteca estándar.

¿Esto de alguna manera haría aceptable comstackr diferentes partes de un proyecto más grande con diferentes opciones de dialecto de lenguaje?

Actualización: Debo añadir una pregunta ortogonal: ¿qué pasa con el uso de dos versiones diferentes de GCC (por ejemplo, 4.3 y 4.6), pero que la misma opción dialecto ( -std=c++98 )? El listado en esta documentación de GCC parece sugerir que la biblioteca es compatible en ambas direcciones entre 4.2.2 y 4.6.

A priori, no. La solución más segura es suponer que todas las opciones del comstackdor son idénticas, excepto cuando el comstackdor documente específicamente que la opción no afecta la compatibilidad binaria. (Documentación que falta en la mayoría de los comstackdores). En la práctica, en la falta de documentación, parece una apuesta segura que las opciones que controlan las advertencias ( -W... en g ++) no afectarán la compatibilidad binaria, y que las opciones que afectar la generación de código (nivel de lenguaje, etc.) podría: g ++ generalmente mantiene la compatibilidad entre los diferentes niveles de optimización, mientras que VC ++ no lo hace.

Otro problema real es definir símbolos de preprocesador en la línea de comando. De nuevo, la apuesta más segura es que todas las definiciones sean idénticas, pero también hay que tener sentido común: no se puede esperar que la biblioteca estándar haya sido comstackda con símbolos preprocesadores que se usan en su proyecto (cosas como MYPROG_CONFIG_FILE_LOCATION , decir). Por otro lado, tenga en cuenta que las definiciones de preprocesador de _GLIBCXX_DEBUG y _GLIBCXX_DEBUG_PEDANTIC afectarán la compatibilidad binaria (aunque g ++ garantiza que obtendrá una versión de biblioteca que funcione con ellas si las usa de forma coherente).

Con respecto a su pregunta: No esperaría tener un gran impacto en la compatibilidad binaria debido a la versión estándar, pero no me sorprendería si la elección afecta algunos símbolos preprocesados ​​predefinidos, de una manera que rompería la compatibilidad binaria en la biblioteca. como si hubiera comstackdo algunos de los módulos con _GLIBCXX_DEBUG y algunos sin. Podría funcionar, pero no contaría con eso.

Sé que, en principio, esto es probablemente un comportamiento indefinido,

No es.

Supongamos que compilo una unidad de transacción con gcc -std=c++98 y otra con -std=c++11 , utilizando exactamente la misma instalación del comstackdor. ¿Hay algún tipo de garantía de que puedo vincular los dos archivos objeto y obtener un progtwig bien definido?

Sí, esto es compatible y funciona (hay excepciones, como habilitar el modo de depuración en un objeto y no en el otro, o usar explícitamente opciones de cambio de ABI como -fshort-enums en una y no en la otra, pero eso debería ser obvio porque eso no funcionará incluso si usa la misma opción -std para ambos objetos).

Por lo que puedo decir, los problemas potenciales solo pueden provenir de diferentes vistas de los encabezados de las bibliotecas debido a las diferentes macros, y estos a su vez agregarían nuevas funciones miembro, pero nunca objetos miembros, a las clases de biblioteca estándar.

Derecha.

¿Esto de alguna manera haría aceptable comstackr diferentes partes de un proyecto más grande con diferentes opciones de dialecto de lenguaje?

Para GCC, sí, absolutamente. Como prueba de que está bien, considere que libstdc++.so contiene algunos objetos creados con -std=c++98 y algunos creados con -std=c++14 .

Actualización: Debo añadir una pregunta ortogonal: ¿qué pasa con el uso de dos versiones diferentes de GCC (por ejemplo, 4.3 y 4.6), pero que la misma opción dialecto (-std = c ++ 98)? El listado en esta documentación de GCC parece sugerir que la biblioteca es compatible en ambas direcciones entre 4.2.2 y 4.6.

No en ambas direcciones, necesitaría usar libstdc++.so desde GCC 4.6 (o más nuevo), porque el objeto comstackdo con esa versión podría depender de los símbolos que se introdujeron en la versión más nueva y que no están presentes en la versión anterior de libstdc++.so biblioteca.

Alguna información relacionada en https://stackoverflow.com/a/49119902/981959

El lenguaje ABI es el mismo, pero STL ABI es diferente. Ver https://gcc.gnu.org/wiki/Cxx11AbiCompatibility

Por lo tanto, no recomiendo mezclar bibliotecas comstackdas con -std = c ++ 98 -std = c ++ 11. Puede obtener lockings al pasar datos a través de los límites de la imagen.

(Puede funcionar si solo llamas a funciones “C” externas y solo pasas POD).

Ver también relacionado: Mezcla diferentes estándares de C ++ con GCC