Discussion :

[Patrick Ruiz]

Que se passerait-il si C++ abandonnait la rétrocompatibilité ? Cela permettrait au langage d’aller vers plus de sécurité et de simplicité
D’après une proposition à l’intention du comité de la norme

L’annonce de la finalisation de la spécification C++ 20 est tombée à mi-parcours de l’année précédente. Comme avec les précédentes, l’un des fils conducteurs est la compatibilité entre la nouvelle version du langage C++ et les précédentes. Mais, il ne devrait plus en être ainsi d’après un groupe de développeurs qui estime que le maintien de l’objectif de rétrocompatibilité ne différencie pas le C++ des autres langages de programmation dans le même couloir : « La priorité devrait aller aux propositions de valeur qui font la singularité du C++ plutôt que de suivre la masse et de régresser à la moyenne. »

Le groupe a donc pris position dans une publication à l’intention du comité de normalisation du langage pour présenter une vision d’évolution du langage centrée sur un certain nombre d’axes dont la performance, la simplicité et la sécurité. Les auteurs suggèrent donc l’abandon de la rétrocompatibilité. De façon précise, la compatibilité qu’elle soit ascendante ou descendante ne fait pas partie de leur plan ; la stabilité de l’interface binaire-programme (ABI) non plus.

« D’après notre expérience, maintenir la stabilité de l'ABI pour les builds de haut niveau représente une charge de conception importante et permanente. Cela devient un obstacle à l'évolution, qui est l'un de nos objectifs déclarés », indiquent-ils. Ils proposent plutôt des migrations d’une version du langage à une autre comme réponse à l’abandon de la compatibilité. C’est sur la base de leur expérience de l’évolution logicielle au fil du temps et de la pertinence d’un modèle qui consiste à gérer le développement en direct sur une base de code unique qu’ils justifient ce positionnement.

En sus, le groupe d’ingénieurs envisage de laisser de côté le modèle de liaison standard et d’introduire la nécessité de procéder à des mises à jour complètes des chaînes d’outils pour chaque nouvelle version du langage C++. D’importants pans de la proposition qui s’inspire des cas d’usage (du langage C++) des auteurs ont fait l’objet de présentation lors de l’édition 2019 de la conférence CppCon.

La proposition a du sens pour des développeurs C++ lancés sur des projets à la durée de vie relativement courte comme ceux de la filière des jeux vidéo. On peut anticiper sur ceci que les bénéfices qu’ils sont susceptibles de tirer des améliorations apportées au langage devraient beaucoup plus peser sur la balance que les coûts de migration qui ont cours avec l’approche actuelle. À contrario, pour des projets qui ont déjà une certaine maturité, cela ne semble pas convenir. En effet, il n’y a pas d’importants ajouts de code nouveau et donc on entrevoit mal en quoi les améliorations du langage peuvent être d’un quelconque profit.

La sortie du groupe d’ingénieurs dont certains travaillent pour des entreprises comme Google laisse entrevoir des divisions qui couvent au sein de la communauté C++. « Nous pensons que de nombreuses questions qui divisent le comité proviennent d'un désaccord en lien avec les priorités », écrit-il. Le groupe de 17 souligne que son positionnement a pour but de faire savoir ce qu’il a comme attentes vis-à-vis du C++ en tant que langage de programmation système à hautes performances. Il n’insiste pas pour obtenir un consensus sur ces points dans l’immédiat.

Source : open-standard

Et vous ?

Voyez-vous aussi la compatibilité entre versions du langage comme un frein à l’évolution du C++ ?
En quoi un fork orienté selon cette proposition serait-il pertinent de votre point de vue ?
À quel type d’organisations pourraient profiter les évolutions proposées par les auteurs ?

Voir aussi :

De C++14 à C++17, qu'est-ce qui a changé avec la nouvelle version du langage C++ : un document de la Standard C++ Foundation
La spécification de la nouvelle version du langage C++ (C++17) est finalisée quelles sont les nouveautés introduites ?
Le premier brouillon de la prochaine révision du standard C, le C2x, est publié et met l'accent sur la compatibilité du langage
Internet aurait de sérieux problèmes à cause de langages comme C et C++ favorisant la survenue de failles mais peu de développeurs s'en soucieraient

[Mat.M]

La proposition a du sens pour des développeurs C++ lancés sur des projets à la durée de vie relativement courte comme ceux de la filière des jeux vidéo

j'aimerais bien savoir pourquoi un projet développé en C++ a une courte durée de vie ,elle est bonne celle-là !
En quoi un programme fait ne serait-ce qu'en Java ou en NET a-t-il une durée de vie plus longue ?
Surtout qu'avec ce genre de langages il faut changer de framework comme on change de chemise; avec .NET il faut metre à jour le framework tous les ans quasiment.
Donc ça ne fait pas du code pérenne tout ça..
pour finir C++ n'est pas plus complexe qu'un autre langage.

[gabriel21]

j'aimerais bien savoir pourquoi un projet développé en C++ a une courte durée de vie ,elle est bonne celle-là !

Je penses qu'il veut dire des logiciels dont la durée de vie ne dépasse pas les 5/10 ans comme ceux des jeux vidéos. Il faut voir la galère pour installer un jeux qui a 10 ans.
Pas le C++ en lui même.
Les moteurs de jeu évolue vite voir très vite et sont toujours à la recherche de performance et pas forcément de stabilité.

Pour ma part, l'abandon de la rétrocompatibilité figerait certains systèmes lourds avec des évolutions lentes et maîtrisées. La stabilité étant le premier objectif et pas forcement la performance. Philosophie que l'on retourve dans tous les systèmes critiques utilisant le C++ et dont aucun utilisateur final ne connaît l’existence, car ils sont un pré requis au reste.
J'y voit en conflit entre deux types de besoins qui sont souvent incompatibles.
Maintenant, cette obsession au changement toujours et partout commence à m’inquiéter. Est ce le signe que le marketing et son mirage du toujours mieux, est entrain de contaminer même les techniques?
Qu'adviendra t il de notre monde quand les systèmes critiques seront aussi fiable qu'une béta parce que tout les 3 ans on changera tout pour faire différent?

[JPLAROCHE]

Bonjour,
sur les gros system l'évolution implique la reprise des programmes existant. Ce n'est pas un problème en soi si on a appliqué la théorie du programme PROPRE ( voir sur dévellopez.net l'article ) ainsi on remet bien en avant la façon de traiter un projet ( pas plus mal ).

Dans certain langage il est possible d'avoir plusieurs versions sur PC donc cela ne pose pas de problème sauf que le manque de cohérence dans la façon de penser car on ne court jamais assez vite pour l'entreprise qui pense qu'il suffit de demander pour que hop cela fonctionne..... Donc l'évolution normalement apporte toujours son lot du +++++ pour répondre.

Je suis personnellement content que l'on y pense à faire un break sur la rétrocompatibilité peut-être pas à toutes les versions et se limiter aux versions majeures.

[gabriel21]

Quand je vois comment est repris l'existant, cela fait parfois sourire.

Quand le nouveau logiciel écrit en java et C# au bout de 10 ans, n'est toujours pas capable d'implémenter toutes les fonctionnalités développés en Cobol, en Fortran, en C/C++ et qu'on est obligé d’acheter des virtualiseurs pour héberger des applications industrielles qui ont 40 ans parce que les serveurs dont certains ont plus de 20 ans sont en train de mourir...
Et l'équipe Java s'arrache les cheveux à chaque montée en version de Java parce que l'application utilise des fonctions dépréciées et supprimées et que l'équipe sécurité exige la nouvelle version de Java sur les postes utilisateurs, déployées automatiquement à distance... Et comme il y a des impératifs fort en terme de fiabilité et sécurité, imposée par la loi...
Je suis bien content de n'être que "administrateur Système" et de ne faire de la programmation que pour mon plaisir et en C++, où je ne suis pas obligé de changer ma façon de coder tout les 3 ans parce qu'un comité l'a décidé ainsi.

[Astraya]

C'est étrange quand même je travail sur un système SIL2 on code en c++ et pourtant la durée de vie est de 20 ans et plus...
Pour ce qui est du jeu vidéo, les problèmes d'aujourd'hui sont l'évolution des technologies (Principalement le rendu qui utilise d'anciennes versions de DirectX). Que ça soit en c, c++, java, c# vous aurez le même problème. La durée de vie d'une application n'a rien à voir avec le language. Je dirais même que pour faire du très longue durée j'aurais tendance à allez vers c c++ qui sont des languages increvables et dans 20 ans ils seront toujours là.
Je suis d'accord avec la proposition, une casse de la retro-compatibilité doit être acceptable de temps en temps.
Aujourd'hui si on reprend un code c ou c++ codé il y a 20 ans on utilise l'ancienne version du compilateur ( qui est souvent dans les specs) et on code avec les normes au moment où les specs ont été faite. Je me vois mal venir mettre du c++20 sur un projet c++98 pour le fun, ou alors c'est un choix réfléchi accepté par le client et l'ensemble des tests et validations sont à refaire.

[Mat.M]

Maintenant, cette obsession au changement toujours et partout commence à m’inquiéter. Est ce le signe que le marketing et son mirage du toujours mieux, est entrain de contaminer même les techniques?

oui c'est tout à fait cela.
Il faut pas perdre de vue que les éditeurs de solutions logicielles tout ce qu'ils veulent c'est vendre leus produits évidemment quitte à faire disparaître des technos "anciennes".
Donc au niveau génie logiciel mettons une SSII qui fait des prestations pour un client ça finit par coûter cher au client contraint de se mettre à jour technologiquement.
Remarquez que s'il faut faire des évolutions logicielles à un projet ça donne du boulot aux programmeurs , faut demeurer opportuniste dans la vie

C'est bien pour cela que dans un projet informatique quel qu'il soit , jeu ou pas, il faut essayer de faire dans le conceptuel un maximum sous forme de classes abstraites et la POO est parfaite pour cela.

Quant à l'évolution techno dans les jeux vidéos Microsoft en resté à Direct X 12 encore donc vous pouvez toujours rattraper le retard.
Ensuite entre Dx9 et DX12 la différence majeure c'est l'introduction de code HLSL pour programmer le GPU

[defZero]

Un langage informatique (pas ces implémentations) n'étant pas "rétrocompatible", ne serait-il pas un "nouveau langage" ?
Je veut bien, mais alors tant qu'a péter la "rétrocompatibilité" autant partir sur quelque chose de plus simple / logique que le C++.

[ParseCoder]

Ca voudrait dire se retrouver potentiellement avec plusieurs dialectes C++. C'est déjà assez compliqué comme ça, si on s'engage là dedans j'ai peur qu'on tue le C++. Mais créer un autre langage système pourquoi pas. Pourquoi pas avec avec une syntaxe proche du C++, mais en partant d'une page blanche. Au lieu de casser des choses par ci par là, repenser un langage dans son ensemble.

[air-dex]

Mais créer un autre langage système pourquoi pas. Pourquoi pas avec avec une syntaxe proche du C++, mais en partant d'une page blanche. Au lieu de casser des choses par ci par là, repenser un langage dans son ensemble.

C'est comme ça qu'on est passé de Speedcoding à Fortran, de Fortran à ALGOL, d'ALGOL à CPL, de CPL à BCPL, de BCPL à B, de B à C, de C à C++ puis de C++ à Java et C#. À eux de continuer l'évolution et de laisser C++ tranquille et à ceux dont le format actuel du langage convient. Cela n'a pas empêché Fortran de faire carrière ensuite donc je ne vois pas pourquoi ça serait différent pour C++.

[Astraya]

C'est ce que fait Rust par exemple. Il est juste très bon comme language. Mais il manque cruellement de la myriade de librairie c et c++ existante. Combien de temps cela prendra-t-il pour avoir le même? Est-ce que Rust durera 40 ans? Je le lui souhaite.
Casser la retro-compatibilité à du bon et du mauvais. En c++,
utiliser les modules et vous ne serez plus rétro-compatible avec les anciens compilateurs, n'est ce pas déjà en soit une cassure de la retro-compatibilité? Je le pense. Ça n'en fait pas un autre language.
Il ne faut pas confondre egalement les languages interprètés et les languages compilés. Le language interprèté dépend de la version et de la compatibilité de son interpréteur. Le language compilé dépend de son matériel.

[Mat.M]

C'est ce que fait Rust par exemple. Il est juste très bon comme language. Mais il manque cruellement de la myriade de librairie c et c++ existante. Combien de temps cela prendra-t-il pour avoir le même? Est-ce que Rust durera 40 ans? Je le lui souhaite.

eh bien pourquoi vous même ne créez pas des bilbios pour Rust ?
Au lieu de discuter ici vous auriez tout vite fait de créer ces bibliothèques

[jo_link_noir]

eh bien pourquoi vous même ne créez pas des bilbios pour Rust ?
Au lieu de discuter ici vous auriez tout vite fait de créer ces bibliothèques

Aujourd'hui, j'ai décidé de porter quelques centaines de milliers de bibliothèques qui touchent des domaines que je ne maîtrise absolument pas dans un langage fondamental différent. Facile, quelques heures et c'est torché... Il faut être réaliste, avec toute la bonne volonté du monde, cela va prendre un bon paquet d'années. On ne transforme pas des milliards de lignes de code en un claquement de doigt.

utiliser les modules et vous ne serez plus rétro-compatible avec les anciens compilateurs

Cette comparaison n'a pas beaucoup de sens. À partir du moment où on n'utilise n'importe quoi d'une nouvelle norme, la compatibilité avec les anciens compilateurs disparaît. Mais on s'en fiche, ce qui compte dans la compatibilité, c'est que l'ancien code fonctionne avec le nouveau.

Dans les faits, un code C++03 peut ne pas compiler en C++11, des classes et fonctions de la STL disparaissent (principalement C++17), etc. La rétro-compatibilité à 100% n'existe déjà pas. La question est de savoir à quel niveau et sur quoi cette rétrocompatibilité est important ? Quelles en sont les conséquences dans la facilité de maintenance, les performances, les risques d'erreurs dans le code, etc ?

Il faut aussi savoir différencier la compatibilité du code et celle binaire. Énormément de changement sont impossibles à faire avec une compatibilité binaire. Alors qu'au niveau code, les changements sont beaucoup plus facile avec un risque des fois très faible, voire nul.

[Astraya]

Cette comparaison n'a pas beaucoup de sens. À partir du moment où on n'utilise n'importe quoi d'une nouvelle norme, la compatibilité avec les anciens compilateurs disparaît. Mais on s'en fiche, ce qui compte dans la compatibilité, c'est que l'ancien code fonctionne avec le nouveau.

Oh je ne prenais ici qu'un exemple parmis toutes les nouvelles fonctionnalité du language. Le mot clé auto par exemple n'est pas dispo en c++98. Et leur utilisation casse la compilation en c++98. Les modules apportent non seulement de nouveaux mots clé mais aussi une toute autre façon d'organiser un projet à mes yeux. Évidemment toutes nouveautés brisent la retro-compatibilité. Certaines ont plus d'impact que d'autres.

[Astraya]

eh bien pourquoi vous même ne créez pas des bilbios pour Rust ?
Au lieu de discuter ici vous auriez tout vite fait de créer ces bibliothèques

Et bien parce que j'ai un boulot, une femme un enfant et je suis en confinement, j'essai de m'en sortir avec ça déjà ahah

[Invité]

Casser la retro-compatibilité à du bon et du mauvais. En c++,
utiliser les modules et vous ne serez plus rétro-compatible avec les anciens compilateurs, n'est ce pas déjà en soit une cassure de la retro-compatibilité? Je le pense. Ça n'en fait pas un autre language.

Ce n'est pas ça, la rétro-compatibilité. La rétro-compatibilité ça veut dire que dans du code C++20, tu peux aussi mettre du code C++03 et ça compilera avec un compilateur C++20. Evidemment qu'un compilateur C++03 ne peut pas compiler du code C++20, mais ça c'est la compatibilité ascendante.

[foetus]

Il faudrait avoir un exemple mais je pense que cela peut être néfaste parce que le C++ risque d'abandonner 1 de ses spécificités et de se rapprocher d'1 autre langage (Java, C#, ...)
Je vois 2 situations.
1) Lors de la normalisation d'1 fonctionnalité, le comité s'est confronté à des difficultés. Je pense au système d'include. Refaire 1 système avec une compilation plus rapide, 1 meilleure intégration aux systèmes d'intégration continu, avoir des "package managers" (autres que NuGet).
Voire enfin ne plus mettre le code template dans l'entête ou des librairies statiques indépendantes du compilateur (si ce n'est pas le cas) ... une meilleure gestion des erreurs avec les template

2) Allez plus loin dans leur idée. Je pense à abandonner les pointeurs (et donc new/ delete et les références) et mettre en avant les pointeurs intelligents. Faire comme le java, des passages par copie pour les POD et par référence pour les objets.
Je ne pense pas à une machine virtuelle, mais éventuellement 1 système à ARC qui met les appels des constructeurs et des destructeurs au bon endroit.

[epsilon68]

le compatibilite ascendante du c++ est une "feature", jamais ca sera adopté.

[Invité]

Il y a eu une proposition d'utiliser un système d' "epochs" en C++, qui peut se mettre en place facilement grâce aux modules:
- Par module: définir une version particulière de C++, en une seule ligne;
- Après la compilation, le code généré est indépendant de cet "epochs" et peut donc s'interfacer avec d'autre version dans d'autres modules.

Ca permettrait de faire une transition simple et en plusieurs temps pour les gros projets.

(Source: http://www.open-std.org/jtc1/sc22/wg...9/p1881r0.html)