ABI des smart pointers n'est pas définie ; donc l'interopérabilité du code n'est garantie que pour des libs headers-only.
Aucune ABI n'est définie pour C++. Et l'ABI est différente suivant les compilateurs (même si Clang et GCC sont alignés) et même dans l'histoire d'un même compilateur (GCC a changé d'ABI C++ plusieurs fois au cours de son histoire, et je ne parle même pas de MSVC). Et en fait, quand tu as une bibliothèque header-only, tu es sûr que ça va marcher partout sans problème d'ABI justement puisque tout est recompilé à chaque fois. Tandis que ta bibliothèque, il faut qu'elle soit compilé quasiment avec la même version de compilateur (notamment sous Windows) que ton programme si tu veux que ça fonctionne sans problème.
on pense à introduire une fonction pour enlever un élément d'un vecteur avant le générateur de gaussiennes.
Parce que ça implique de maintenir plein de choses dans le langage juste pour conserver cette compatibilité, ce qui freine l'évolution du standard.
C'est un choix. Que ce choix soit critiquable, OK. Mais ce choix est le résultat d'un consensus : les gens qui font du C++ sérieusement préfèrent avoir une compatibilité. Même s'il la casse quand même quand c'est nécessaire. Personne ne t'oblige à l'utiliser.
En C++, on a toujours pas de librairies pour le système de fichiers.
Si justement, on en a une maintenant. C'est la même que celle de Boost. Et croire que gérer un système de fichier, c'est facile, c'est se tromper lourdement. Parce que C++ étant compatible avec C, et C étant à la base des systèmes d'exploitation, il faut être compatible avec toutes les bizarreries. Comme par exemple le fait que sous Unix, les noms de fichiers soit des char * mais sous Windows des wchar_t *. Juste ça, ça fout le merdier pour faire un code portable. Avec un langage neuf, tu peux te permettre de cacher ça et de faire des conversions. Mais en C++ où tu t'attends à de la performance, tu dois en tenir compte et faire avec.
Et pour ça, C++ ne part pas gagnant.
Sauf que C++ ne part pas, il est déjà très bien installé et n'est pas près de bouger. Des projets C++ se créent tous les jours.
[^] # Re: Donc pour résumer...
Posté par rewind (Mastodon) . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 6.
Aucune ABI n'est définie pour C++. Et l'ABI est différente suivant les compilateurs (même si Clang et GCC sont alignés) et même dans l'histoire d'un même compilateur (GCC a changé d'ABI C++ plusieurs fois au cours de son histoire, et je ne parle même pas de MSVC). Et en fait, quand tu as une bibliothèque header-only, tu es sûr que ça va marcher partout sans problème d'ABI justement puisque tout est recompilé à chaque fois. Tandis que ta bibliothèque, il faut qu'elle soit compilé quasiment avec la même version de compilateur (notamment sous Windows) que ton programme si tu veux que ça fonctionne sans problème.
Un truc comme vector::erase qui existe depuis 98 ?
C'est un choix. Que ce choix soit critiquable, OK. Mais ce choix est le résultat d'un consensus : les gens qui font du C++ sérieusement préfèrent avoir une compatibilité. Même s'il la casse quand même quand c'est nécessaire. Personne ne t'oblige à l'utiliser.
Si justement, on en a une maintenant. C'est la même que celle de Boost. Et croire que gérer un système de fichier, c'est facile, c'est se tromper lourdement. Parce que C++ étant compatible avec C, et C étant à la base des systèmes d'exploitation, il faut être compatible avec toutes les bizarreries. Comme par exemple le fait que sous Unix, les noms de fichiers soit des
char *mais sous Windows deswchar_t *. Juste ça, ça fout le merdier pour faire un code portable. Avec un langage neuf, tu peux te permettre de cacher ça et de faire des conversions. Mais en C++ où tu t'attends à de la performance, tu dois en tenir compte et faire avec.Sauf que C++ ne part pas, il est déjà très bien installé et n'est pas près de bouger. Des projets C++ se créent tous les jours.