IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Patrick Ruiz

82PARTAGES

9  0 
Êtes-vous pour un fork de C++ qui casse avec la compatibilité entre versions du langage ?
Non, c'est inutile car le C++ évolue de toutes les façons
46 %
Oui, c'est primordial pour l'introduction de certaines évolutions
42 %
Pas d'avis
8 %
Autres (à préciser)
4 %
Voter 26 votants
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 09/04/2020 à 12:21
Citation Envoyé par Patrick Ruiz Voir le message
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.
8  1 
Avatar de gabriel21
Membre chevronné https://www.developpez.com
Le 09/04/2020 à 14:23
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.
6  1 
Avatar de gabriel21
Membre chevronné https://www.developpez.com
Le 09/04/2020 à 13:01
Citation Envoyé par Mat.M Voir le message
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?
6  2 
Avatar de Astraya
Membre chevronné https://www.developpez.com
Le 09/04/2020 à 16:34
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.
5  1 
Avatar de Astraya
Membre chevronné https://www.developpez.com
Le 10/04/2020 à 13:05
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.
3  0 
Avatar de jo_link_noir
Membre expert https://www.developpez.com
Le 10/04/2020 à 15:21
Citation Envoyé par Mat.M Voir le message
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.
3  0 
Avatar de
https://www.developpez.com
Le 10/04/2020 à 18:22
Citation Envoyé par Astraya Voir le message
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.
3  0 
Avatar de
https://www.developpez.com
Le 11/04/2020 à 15:14
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/wg21/docs/papers/2019/p1881r0.html)
3  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 09/04/2020 à 22:02
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++.
3  1 
Avatar de ParseCoder
Membre averti https://www.developpez.com
Le 10/04/2020 à 11:16
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.
4  2