C'est surtout un problème d'incompatibilité binaire du C++ en fait,
Non. C'est juste Microsoft qui a ces incompatibilités.
De son coté, GCC maintiens une bien meilleur compatibilité binaire.
Le dernier changement date de libstdc++-v3 (libstdc++.so.6) sorti avec GCC 3.4.0 en 2004 (il y a 9 ans!)
Et reste compatible même après le passage à C++11.
(Note que C++11 rajoute quelque règle qui nécessite un changement dans l'ABI, comme le fait que std::list::size soit O(1) ou qui interdit à std::string de faire du « copy on write ». Les dev de GCC ont décidé de repousser ces changements à la prochaine version majeure de la libstdc++)
(Ah, je rajoute que C++11 introduit les « inline namespace », qui permet de facilité la compatibilité binaire des bibliothèque en C++. C'est utilisé par la libc++ du projet llvm)
il s'agissait de faire fonctionner un code compilé avec une libstdc++ récente sur une machine avec des versions plus anciennes
C'est plus problématique, surtout si le programme fait appel à des nouveauté de tr1 ou de C++11
[^] # Re: Pendant ce temps...
Posté par Gof (site web personnel) . En réponse à la dépêche C++11 : sur le fil. Évalué à 6.
Non. C'est juste Microsoft qui a ces incompatibilités.
De son coté, GCC maintiens une bien meilleur compatibilité binaire.
Le dernier changement date de libstdc++-v3 (libstdc++.so.6) sorti avec GCC 3.4.0 en 2004 (il y a 9 ans!)
Et reste compatible même après le passage à C++11.
(Note que C++11 rajoute quelque règle qui nécessite un changement dans l'ABI, comme le fait que std::list::size soit O(1) ou qui interdit à std::string de faire du « copy on write ». Les dev de GCC ont décidé de repousser ces changements à la prochaine version majeure de la libstdc++)
(Ah, je rajoute que C++11 introduit les « inline namespace », qui permet de facilité la compatibilité binaire des bibliothèque en C++. C'est utilisé par la libc++ du projet llvm)
C'est plus problématique, surtout si le programme fait appel à des nouveauté de tr1 ou de C++11