Alors il s'agit plus de définir une ABI compatible entre les différents "vendors",
mais du moins ça a été discuté dans le C++ Committee Meeting de juin 2014
C'est un bon pas en avant, mais ça ne corrige malheureusement pas le problème.
Ce qu'ils essaient de corriger est principalement les problèmes de compatibilités entre les binaires des différents compilateurs. Ce qui est au passage un autre cauchemar du C++. L'inlining / le mangling changeant au grés des versions, il n'est pas rare qu'une bibliothèque compilée avec GCC et utilisée avec clang... ne plus link plus proprement à la prochaine version de GCC (et je ne parle même pas de MSVC ahah )
Les principaux problèmes d'ABI causant des mots de têtes aux packagers sont assez différents.
L'un vient du fait que la taille des types est décidée à la compilation en C++. Ce qui signifie que modifier un data membre d'une class publique sans utiliser le pattern Pimpl/d_ptr est une catastrophe. Une solution à ça pourrait être le proposal N4025 si défini proprement.
L'autre vient de la vtable. Le polymorhisme en C++ est implémenté via un vtable, ce qui est excellent en terme de performance mais à chier en terme de maintenabilité.
La seul solution que je vois à ce problème serait la définition d'un type "Super-class" qui substitue la vtable pour un système un peu plus sain en terme de maintenabilité.
[^] # Re: Quelqu'un peut-il m'expliquer le problème avec l'ABI de KDE
Posté par Firwen (site web personnel) . En réponse au journal Pourquoi empaqueter KDE prend-il du temps ?. Évalué à 5. Dernière modification le 18 août 2014 à 13:09.
C'est un bon pas en avant, mais ça ne corrige malheureusement pas le problème.
Ce qu'ils essaient de corriger est principalement les problèmes de compatibilités entre les binaires des différents compilateurs. Ce qui est au passage un autre cauchemar du C++. L'inlining / le mangling changeant au grés des versions, il n'est pas rare qu'une bibliothèque compilée avec GCC et utilisée avec clang... ne plus link plus proprement à la prochaine version de GCC (et je ne parle même pas de MSVC ahah )
Les principaux problèmes d'ABI causant des mots de têtes aux packagers sont assez différents.
L'un vient du fait que la taille des types est décidée à la compilation en C++. Ce qui signifie que modifier un data membre d'une class publique sans utiliser le pattern Pimpl/d_ptr est une catastrophe. Une solution à ça pourrait être le proposal N4025 si défini proprement.
L'autre vient de la vtable. Le polymorhisme en C++ est implémenté via un vtable, ce qui est excellent en terme de performance mais à chier en terme de maintenabilité.
La seul solution que je vois à ce problème serait la définition d'un type "Super-class" qui substitue la vtable pour un système un peu plus sain en terme de maintenabilité.