C++ 20 est publié avec de nouvelles fonctionnalités pour le langage et la bibliothèque

Citation:

---

Envoyé par Bousk

Si tu supprimes la fonction virtual de la classe mère et que la classe fille a la fonction déclarée virtual override, alors si les check d'override ne sont pas renforcés ta classe déclare maintenant une fonction virtual en plus/trop.

---

Quelle est cette histoire de « check renforcé » ? Si override est ignoré en présence de virtual, alors le compilateur n'est pas conforme à la norme.

Citation:

---

Envoyé par Bousk

rétro-compatibilité

---

Ce que veut stardeath, c'est pouvoir préciser le numéro de version de C++ utilisé et ne renforcer les restrictions que dans le code associé à la nouvelle version du C++. Les programmes seraient alors un assemblage :

• de code écrit en vieux C++, dans lequel les nouvelles restrictions ne seraient pas imposées (par soucis de rétro-compatibilité), et
• de code écrit en nouveau C++, dans lequel on pourrait utiliser les nouvelles fonctionnalités, mais en respectant les nouvelles restrictions.

Comme le reste, tu peux désactiver les warning, certains ne considèrent pas les warning comme erreur, d'autres ne compilent pas en Wall etc.
Oui c'est con, mais oui tu trouveras des personnes pour se plaindre du langage ou du compilateur alors qu'ils ou un membre de leur équipe ont sciemment désactivé un warning quelques mois plus tôt. Et bien sûr l'ont oublié ou n'avaient aucune idée de ce qu'ils faisaient réellement. Ou plus vicieux : une codebase qui se préparait à la nouvelle norme et fait un define de OVERRIDE, qui n'a pas été mis à jour en upgradant le compilo et est toujours vide.
Tu as aussi des versions de compilo intermédiaires qui font du support partiel, ou supportent les nouvelles fonctionnalités via options uniquement pour laisser aux équipes le temps de mettre à jour la codebase.
Quand tu as la chance de pouvoir utiliser un compilateur à jour.

merci Pyramidev ; le but n'est pas d'emmerder le code existant, même moi je ne veux pas ça, j'ai du code que je veux continuer à utliser, qui est testé, fonctionne, etc. etc.

le but c'est d'essayer de rendre la syntaxe cohérente par rapport aux fonctionnalités proposées, ce qui aurait 2 avantages, un langage plus clair à la lecture, et simplifier l'ajout de nouvelles syntaxes.
le problème actuel est simple, pour ajouter quelque chose de nouveau, le comité est obligé d'utiliser des artifices parce que plus grand chose ne peut rentrer dans la grammaire à cause de son inconsistance.
et je dis juste que ça ne va aller qu'en s'empirant.

après si la seule chose qu'on me répond c'est "rétrocompatible" alors que j'ai déjà abordé et répondu à ce point, je ne peux rien faire pour vous.

Citation:

---

Envoyé par Bousk

Ce sont surtout 2 termes qui n'ont rien à voir, même si override implique virtual l'inverse n'est pas vrai. virtual ici n'est pas nécessaire, est redondant et contre-productif.

---

rien à voir, rien à voir, mais que 2 termes impliquent un troisième et qu'il n'y a pas d'autre cas d'utilisation pour toi ça n'a rien à voir? :ptdr: (précision, dans le contexte d'une méthode, sinon on va me sortir que c'est pas vrai pour essayer de détourner le sujet actuel)
comme dit précédemment, je veux bien omettre l'écriture de virtual si je mets override, mais vu qu'ils ne sont pas écrit au même endroit, il me manque une info au premier coup d'oeil, ce qui est dommageable.

Citation:

---

Envoyé par stardeath

et en parlant de ce cas particulier, puisque c'est une bonne pratique de les mettre, pourquoi finalement ne pas les imposer?

---

Parce que ça casse la compatibilité avec le code legacy qui en est dépourvu. Les compilos modernes émettent cependant un warning... qui peut librement être converti en erreur... des outils open source peuvent réécrire et migrer automatiquement le code legacy... n'est-ce pas suffisant?

Citation:

---

Envoyé par stardeath

et, perso, si on doit en mettre qu'un, j'aurais été le premier content à écrire "override void toto()".

---

pour que cette syntaxe fonctionne, il faut que override soit un nouveau mot clé réservé et non plus un mot clé contextuel, ce qui a pour conséquences de briser la compatibilité: la moindre ligne de code avec une variable ou une fonction nommée "override" ne compilera plus. A titre d'exemple, chez Google c'est plus de 250M de LOC qu'il faut migrer à chaque nouvelle norme...

Citation:

---

Envoyé par stardeath

on va encore dire que je m'énerve, mais en quoi c'est du troll?, c'est fou quand même une fois de plus cette propension à dénigrer les propos auquel vous n'adhérez pas, de plus, on est pas sur d'autre langage, on est sur le c++. donc si vous ne voulez pas argumenter ou autre, abstenez vous, vous verrez c'est encore plus facile que d'essayer de tourner en dérision des propos ...
et même, donc on met un truc bien pour faire passer la pilule du truc moins bien? c'est quoi cette logique?

---

ben la logique à questionner c'est d'abord la tienne : c'est toi qui t'acharnes à dénigrer le langage sur la base d’éléments plutôt... subjectifs. J'ai dit que c'est du troll parce qu'on coupe les cheveux en quatre sur un point de détail dans le but de démontrer la faiblesse syntaxique du langage et la stupidité du comité de normalisation, tout en se gardant bien de donner des exemples où la syntaxe C++ est plus simple que dans bien des langages, ni se poser plus humblement la question de pourquoi la comité a pris telle ou telle décision à l'issu de plusieurs années de délibération pour mieux conclure "puisque je n'y vois aucun intérêt, c'est forcément que c'est stupide".

Des critiques sur C++ j'en ai entendu un paquet, mais jamais sur override en fin de prototype. Toi même admet que c'est parce que tu dois parser le langage dans un contexte bien précis que ça te pose problème. Mais sinon, quand on a pris l'habitude de déclarer ses fonction const, ça choque pas plus que ça (et pour les long noms de fonction y'a clang-format qui fait très bien le job).

A savoir beaucoup de pistes ont été étudiées et débattues pour le cas d'override (comme tout le reste d'ailleurs), et la lisibilité du langage est toujours au coeurs des débats. Il suffit de chercher un peu sous Google pour avoir le détail des propositions avec argumentation de leur rejet:
http://www.open-std.org/jtc1/sc22/wg...2005/n1827.htm
http://www.open-std.org/jtc1/sc22/wg...009/n2852.html

Citation:

---

Envoyé par stardeath

j'écris des outils d'analyses du code c++, je sais pas si vous imaginez le bordel que c'est de gérer le simple cas du virtual/override/final ; le tout avec un bénéfice de la rétrocompatibilité syntaxique, pour moi, nul.

---

tu ne peux pas t'appuyer sur un front-end éprouvé qui fait déjà tout ça pour toi?

ok, avec mon modèle en tête, et parfaitement résumé par Pyramidev :

Citation:

---

Envoyé par Pyramidev

- de code écrit en vieux C++, dans lequel les nouvelles restrictions ne seraient pas imposées (par soucis de rétro-compatibilité), et
- de code écrit en nouveau C++, dans lequel on pourrait utiliser les nouvelles fonctionnalités, mais en respectant les nouvelles restrictions.

---

donnez moi un exemple concret de truc, qui fonctionnerait correctement avec le c++ tel que le comité l'a designé actuellement et qui ne fonctionnerait pas avec mon modèle.
une fois de plus on me sort la compatibilité alors que j'ai conçu mon modèle pour qu'il le soit, donc maintenant prouvez vos propos.

et de la même manière que vous me parlez de ne pas foutre en l'air votre code legacy, je ne peux pas foutre en l'air le code legacy, pour le réécrire avec des nouveaux outils qui ferait sans doute parfaitement le travail.

Citation:

---

Envoyé par stardeath

donnez moi un exemple concret de truc, qui fonctionnerait correctement avec le c++ tel que le comité l'a designé actuellement et qui ne fonctionnerait pas avec mon modèle.

---

Si j'ai bien compris ta proposition, c'est de pouvoir fixer unité de compilation par unité de compilation la version du C++ à utiliser (voire descendre la granularité à la fonctionnalité). Est-ce bien ça ?

Si oui, j'ai du mal à voir comment ça peut s'articuler avec le mécanisme actuel d'include (remarque déjà faite par Pyramidev), je ne sais pas si se serait plus réalisable avec les modules de C++20 (je n'ai pas regardé la proposition sur les modules assez en détail).
Et un réglage par projet, outre que c'est ce que font déjà les compilateurs, ne résout pas le problème.

Certes, c'est un problème des include et non de ton idée elle-même mais ça la rend difficilement applicable pour l'instant.
Au passage, vu que nous parlons de défauts du C++, ces fichus include en sont un très bel exemple. Et le temps que les modules sortent, soient supportés par tous les compilateurs et que le code migre vers ceux-ci, je pense qu'il va falloir les supporter encore très longtemps.

A part ce point, ton idée est plutôt bonne et j'apprécierais vraiment ce type de fonctionnement.


Et si j'ai mal saisi ta proposition, je veux bien que tu précises un peu.

Citation:

---

Envoyé par gl

Si j'ai bien compris ta proposition, c'est de pouvoir fixer unité de compilation par unité de compilation la version du C++ à utiliser (voire descendre la granularité à la fonctionnalité). Est-ce bien ça ?

---

Je pense que cela va plus loin :mrgreen: Tu vas mélanger des fichiers .cpp/ .h, .hpp (C++-03) avec des fichiers .cpp11[/ .hpp11] et/ ou des fichiers .cpp14[/ .hpp14] et/ ou des fichiers .cpp17[/ .hpp17]

Cela me fait penser à Visual C++ :mrgreen: : au début, il regardait l'extension .c ou .cpp pour savoir comment compiler et qu'ensuite, il compilait tout en C++ (avec une option pour forcer le compilateur)

merci gl pour ta réponse, je pense que tu as saisi mon propos.

pour la granularité (pour fixer la "version") de la syntaxe à utiliser, j'ai effectivement mentionné par unité de compilation, ce qui soulève les points que tu mentionnes ;
on pourrait l'avoir par fichier sur la ligne de commande, ce qui nécessiterait de mettre les .h (et leur version) dans la ligne de commande ;
ou beaucoup plus fin, en attribut, que ça soit en tête de fichier, de classe, de fonctions, etc. (https://en.cppreference.com/w/cpp/language/attributes)

on garderait un réglage global du projet, comme réglage par défaut, avec la version "maximale" de la syntaxe à utiliser, et on flaggerait le code legacy comme tel (par fichier, en attribut, etc.).
lorsqu'un besoin de mettre à jour du code legacy est nécessaire, on peut soit mettre un attribut sur le code en question, qui override le réglage précédent (par exemple dans un fichier "c++03", mettre un attribut "c++11" à une fonction en particulier),
soit déplacer ce code vers un nouveau fichier compilé avec le réglage par défaut.
le problème majeur à ça que je vois c'est faire en sorte de pouvoir mettre à jour la déclaration des classes sans casser l'implémentation existante, donc avoir la possibilité de séparer la version de syntaxe pour la déclaration d'une classe de la version pour l'implémentation de cette classe.
cela me semble loin d'être impossible, vu que ce qui importe dans ce cas c'est de garder la même organisation en mémoire.

le but ultime étant d'être capable d'identifier facilement la version d'un code et surtout de pouvoir mélanger plusieurs versions courante et legacy dans un même binaire ; mais garder un seul et unique compilateur capable de compiler plusieurs versions d'une syntaxe, ce qui est le cas aujourd'hui, mais avec un seul réglage global.
les plus gros problème étant les mêmes qu'en c++ actuel, que fait t'on par exemple en cas de changement de modèle mémoire, ou encore par exemple les changements de contrats pour les list et les string qui ont abouti à un changement d'abi pour gcc.

@foetus, oui effectivement, le but idéal pourrait être de faire confiance (jusqu'à un certain point) au compilo pour identifier et compiler le code avec son bon niveau de fonctionnalités, pour moi, tant que ce qu'il est compilé est binairement compatible, il ne devrait pas trop y avoir de problème.
on est actuellement capable d'avoir des binaires et des bibliothèques dynamiques qui peuvent être écrites dans différent langage pourvus qu'on garde la même interface pour communiquer, je propose d'étendre la philosophie de ce système à l'intérieur du langage.

j'espère juste que ça ne lève pas de contraintes débiles et/ou non solubles, dans ce cas, effectivement, ça ne vaudrait pas le coup.

Citation:

---

Envoyé par stardeath

pour la granularité (pour fixer la "version") de la syntaxe à utiliser, j'ai effectivement mentionné par unité de compilation, ce qui soulève les points que tu mentionnes ;
on pourrait l'avoir par fichier sur la ligne de commande, ce qui nécessiterait de mettre les .h (et leur version) dans la ligne de commande ;
ou beaucoup plus fin, en attribut, que ça soit en tête de fichier, de classe, de fonctions, etc. (https://en.cppreference.com/w/cpp/language/attributes)

on garderait un réglage global du projet, comme réglage par défaut, avec la version "maximale" de la syntaxe à utiliser, et on flaggerait le code legacy comme tel (par fichier, en attribut, etc.).
lorsqu'un besoin de mettre à jour du code legacy est nécessaire, on peut soit mettre un attribut sur le code en question, qui override le réglage précédent (par exemple dans un fichier "c++03", mettre un attribut "c++11" à une fonction en particulier),
soit déplacer ce code vers un nouveau fichier compilé avec le réglage par défaut.
le problème majeur à ça que je vois c'est faire en sorte de pouvoir mettre à jour la déclaration des classes sans casser l'implémentation existante, donc avoir la possibilité de séparer la version de syntaxe pour la déclaration d'une classe de la version pour l'implémentation de cette classe.
cela me semble loin d'être impossible, vu que ce qui importe dans ce cas c'est de garder la même organisation en mémoire.

---

C'est à approfondir et à voir dans les différents cas de figure. Mais à froid, j'ai tendance à penser (que ce soit par fichier, classe, fonction, namespace ou autre) que tu vas avoir des soucis lorsque tu vas vouloir utiliser un truc [1] utilisant des fonctionnalités d'une version X (et donc marqué comme version X) dans un autre truc qui lui doit rester en version Y (car utilisant des fonctionnalités supprimées en X), ce que le fonctionnement actuel permet puisque les fonctionnalités de X sont encore présentes en Y [2].

Certes ça ne concerne qu'une partie du code existant et que certaines fonctionnalités, mais je doute que ce soit complétement négligeable.
Je vois bien des solutions pour s'en sortir, mais rien de vraiment satisfaisant :

• Découpage des trucs pour ne pas rentrer dans ce cas ou mise en place de proxy pour masquer les différences : mais c'est du travail en plus et l'apparition de code complétement ad hoc.
• Compter sur la "magie" du compilateur pour traiter et masquer tout ça : je ne suis pas vraiment fan et, là encore à froid, j'ai l'impression que c'est un travail conséquent dans les compilos.
• Déprécier avant de supprimer pour conserver les fonctionnalités de Y dans les deux-trois versions suivantes et de migrer en douceur : c'est peu ou prou la solution actuelle mais à une échelle plus grande (et donc avec une charge plus importante de migration qui du coup est moins en douceur ou avec des durées de dépréciations beaucoup plus longues avec les risques de prolonger encore et toujours que cela implique)

Il faudrait voir également, mais là on sort de mon domaine, si ce n'est pas prendre le risque de perdre des optimisations possibles du compilateur.



[1] Par truc, j'entends le fichier, la classe, la fonction, etc. qui correspond à la granularité auquel on se trouve.
[2] Je laisse de côté les fonctionnalités supprimées même à l'heure actuelle pour les raisons évoquées précédemment concernant la compatibilité et car il y les durées de dépréciation qui permettent une migration "en douceur" (bon ça reste relatif).

effectivement, la suppression de fonctionnalités posent problèmes pour tout faire fonctionner simultanément.

imaginons la situation où du code c++X et c++Y fonctionnent en même temps avec une fonction toto qui disparaît car dépréciée en c++Z (avec Z étant la version la plus à jour).
je pense qu'on peut considérer que si on veut ajouter du code c++Z au projet existant, il faut faire en sorte de supprimer l'utilisation de toto des codes c++X et Y, on peut pas prolonger à l'infini la vie de l'ancien code et des fonctionnalités supprimées. (j'espère que j'ai bien compris ton exemple)

je pense que ça se rapproche du cas de l'auto_ptr, existant, puis déprécié et finalement supprimer, les périodes de temps étant en effet difficile à fixer.
je penche donc pour le troisième cas ; le premier demande du taf à perte, et pour le second cas, ça pourrait fonctionner si on isole le code problématique dans un composant séparé, mais pareil, quid des interactions avec le reste du code.

pour les optimisations du compilo, je ne me fais pas trop de soucis, on aurait pareil que maintenant : l'ancien code utilisant des designs pouvant être contre productif avec les améliorations des compilos, ne peut pas être amélioré magiquement quoi qu'il arrive, il fonctionnera mais demandera à être réécrit pour profiter des boost.

pour l'instant, j'ai pas l'impression qu'on ait plus de problème que le design actuel du c++.

Citation:

---

Envoyé par stardeath

effectivement, la suppression de fonctionnalités posent problèmes pour tout faire fonctionner simultanément.

imaginons la situation où du code c++X et c++Y fonctionnent en même temps avec une fonction toto qui disparaît car dépréciée en c++Z (avec Z étant la version la plus à jour).
je pense qu'on peut considérer que si on veut ajouter du code c++Z au projet existant, il faut faire en sorte de supprimer l'utilisation de toto des codes c++X et Y, on peut pas prolonger à l'infini la vie de l'ancien code et des fonctionnalités supprimées. (j'espère que j'ai bien compris ton exemple)

je pense que ça se rapproche du cas de l'auto_ptr, existant, puis déprécié et finalement supprimer, les périodes de temps étant en effet difficile à fixer.
je penche donc pour le troisième cas ; le premier demande du taf à perte, et pour le second cas, ça pourrait fonctionner si on isole le code problématique dans un composant séparé, mais pareil, quid des interactions avec le reste du code.

---

Mais dans ce troisième cas (c.-à-d. avec une dépréciation avant suppression) :

• Est-ce que la possibilité de spécifier une version cible est encore efficace ? La conséquence immédiate me semble de spécifier une unique version, généralement la plus récente, et de ne pas en changer sauf éventuellement à la marge. Et en parallèle de migrer tranquillement le code.
• Dans une même version, se trouvent des fonctionnalités récentes et des fonctionnalités dépréciées de versions précédentes. Au final, on se retrouve plus ou moins dans la situation actuelle, si ce n'est peut être la taille du périmètre déprécié, non ?

Et là, le nerf de la guerre va être la capacité à supprimé rapidement les fonctionnalités dépréciées mais pour ça il va falloir convaincre les gens de migrer rapidement. Et c'est sur ce point que se heurtent les volontés de changement des langages qui se voient contraint de conserver les syntaxes dépréciées (et ce n'est pas propres au C++).

Citation:

---

Envoyé par stardeath

pour les optimisations du compilo, je ne me fais pas trop de soucis, on aurait pareil que maintenant : l'ancien code utilisant des designs pouvant être contre productif avec les améliorations des compilos, ne peut pas être amélioré magiquement quoi qu'il arrive, il fonctionnera mais demandera à être réécrit pour profiter des boost.

---

Ce n'est pas tant le problème de la non optimisation du code ancien qui me gêne que la possibilité de bloquer la propagation de certaines optimisation sur les changements de version supportée. Ce qui m'interroge ici, c'est la capacité d'effectuer des optimisations globales lorsqu'une fonction en version X est appelée par une fonction en version Y ou qu'une déclaration de classe peut être vue en version X ou Y selon l'utilisateur.
C'est, si j'ai bien compris mais encore une fois je ne suis pas spécialiste et je fais peut-être fausse route, ce qui se produit aux interfaces entre bibliothèques ou entre bibliothèque et exécutable.

Mais bon ce n'est pas le plus important dans un premier temps.

Citation:

---

Envoyé par stardeath

pour l'instant, j'ai pas l'impression qu'on ait plus de problème que le design actuel du c++.

---

Je suis d'accord, mais je ne suis pas persuadé qu'il ait un réel gain non plus [1].



[1] Encore une fois, je parle dans le cadre du fonctionnement actuel et notamment du mécanisme d'include. Avec d'autres mécanismes, la donne serait différente et l'intérêt pourrait être réel.

je vais pas y réfléchir plus ce matin, mais le but n'est pas non plus le plus spectaculaire, je ne rajoute pas une révolution comme les concepts au c++ ;
j'essaie de faire en sorte de pouvoir nettoyer la syntaxe d'un langage sur un plus ou moins long terme, le tout en cassant le moins de chose possible, chose qui est impossible avec le modèle actuel.

si je n'aimais pas un minimum le c++, j'irai faire du c#, je gagnerai mieux ma vie sur un langage pour l'instant plus logique.

Citation:

---

Envoyé par stardeath

je vais pas y réfléchir plus ce matin, mais le but n'est pas non plus le plus spectaculaire, je ne rajoute pas une révolution comme les concepts au c++ ;

---

J'ai bien compris ce point, et ce n'est pas le problème. Il y a eu un certain nombre d'évolutions minimes qui m'ont tout autant intéressé que de vraies révolutions (au hasard, le constructeur de fstream depuis std::string ou la correction de >> dans les templates imbriqués). Ce n'est pas à mon sens un critère d'intérêt.

Citation:

---

Envoyé par stardeath

si je n'aimais pas un minimum le c++, j'irai faire du c#, je gagnerai mieux ma vie sur un langage pour l'instant plus logique.

---

Pour le côté plus logique, je ne sais pas je ne connais pas assez C# pour juger, mais je te crois volontiers. Par contre pour gagner mieux sa vie, ça ne correspond pas à mon expérience, mais je suis dans un contexte particulier qui l'explique très certainement.
Mais ce n'est pas le sujet de mes commentaires. Ce n'est pas parce qu'on critique un langage qu'on ne l'apprécie pas (pour le coup, je l'apprécie et pourtant j'ai de nombreux reproches à lui faire) et ce n'est pas parce qu'on ne l'apprécie que les critiques ou les propositions d'amélioration ne sont pas pertinentes.

Citation:

---

Envoyé par stardeath

j'essaie de faire en sorte de pouvoir nettoyer la syntaxe d'un langage sur un plus ou moins long terme, le tout en cassant le moins de chose possible, chose qui est impossible avec le modèle actuel.

---

La possibilité de déprécier puis de supprimer une fonctionnalité (voire de la supprimer directement dans quelques rares cas) existe déjà et est dans les fait utilisée. Et la proposition de choisir la version ciblée plus finement toute intéressante qu'elle soit dans l'absolue n'est pas indispensable pour le faire.

Bref il est déjà techniquement possible de nettoyer le langage. Ce qui bloque c'est la volonté de certains membres du comité qui au final reflète peut être leur avis mais aussi et surtout celui de leurs clients. Et ça ta proposition ne peut changer la donne que s'il n'est pas nécessaire de conserver à court terme des fonctionnalités dépréciées dans les versions récentes, ce qui n'est pas possible en l'état du langage.

Il est assez intéressant de voir que de toutes les stratégies qui ont été tenté pour nettoyer le langage (au moins celle que je connais), que ce soit de passer par des cycles de dépréciations/suppressions point par point, rétro-compatibilité absolue en attendant la disparition de l'ancienne syntaxe, suppression sèche, version parallèle du langage (à la Python ou D), ont toute rencontré les mêmes limites et lorsque cela a abouti, c'est avec le temps et surtout l'adhésion des utilisateurs. Il me semble donc que c'est un travail au long cours, assez indépendamment des mécanismes proposés, et qui passe par l'éducation (au sens le plus large du terme).


En tout cas je te remercie de cet échange. Outre ta proposition qui est, je le répète, intéressante, ça m'a fait réfléchir sur certains points que je n'avais jamais questionné et c'est appréciable.

Citation:

---

Envoyé par stardeath

donnez moi un exemple concret de truc, qui fonctionnerait correctement avec le c++ tel que le comité l'a designé actuellement et qui ne fonctionnerait pas avec mon modèle.

---

Pour moi le modèle que tu proposes ne concerne pas le langage mais le build système : tu peux très bien le mettre en place à l'heure actuelle avec cmake ou outil équivalent. C'est à ce genre d'outil qu'incombe la gestion de versions et autres options de compilation par fichier, pas au langage. Mais si tu tiens absolument à gérer ça dans le code, c'est techniquement possible depuis longtemps via le préprocesseur, et c'est plus un truc qu'on fait quand on a vraiment pas le choix (période de transition) car c'est très dommageable pour la lisibilité du code.

Ensuite, de mon point de vue, le modèle idéal que tu as en tête comporte de grosses lacunes qui ne manqueront pas de rapidement se retourner contre toi si tu imposes ça dans une grosse équipe : ça va être le défilé de critiques envers toi, dont certaines qui peuvent potentiellement être très agressives car tu empêches des gens de travailler. Pourquoi ?

Tout simplement parce qu'un code écrit dans une vielle version du langage et un autre dans une version récente, dans la vraie vie, ça n'existe pas. Le nouveau code se greffe par dessus l'ancien : ça commence par un fichier de 2000 lignes écrits en C++98, puis on ajoute/modifie 1000 lignes en C++11, 500 en C++14, 200 en C++17 au fil des années. Et ce que tu veux absolument éviter c'est :
- figer un code dans une version précise de C++ : cela condamne ton code à la mort et te met en danger vis à vis de ton écosystème qui va cesser de supporter cette version à un moment donné (lib tierces...)
- devoir mettre à niveau 2000 lignes de C++98 (avec impact sur le code qui en dépend...) avant de pouvoir rajouter une seule ligne plus moderne dans un fichier existant

Aussi, techniquement parlant, passé un certaine taille / un certain nombre de dépendances, il est risqué voire impossible de mélanger du code compilé dans des modes différents (l'ABI de C++ n'est pas stable). Pour rappel les types aussi courant que std::string changent d'une version de compilo à l'autre et ne peuvent donc pas être mélangées. Qui plus est, recompiler son vieux code en mode récent apporte des gains de perf qui peuvent être significatifs (la move semantic dans la STL a d'ailleurs été conçue pour ça: augmenter les perfs de ton code legacy sans avoir à le retoucher).

Typiquement, chaque gros projet va avoir quelques fichiers qui centralisent une grosse partie de l'application et dépassent l'entendement en terme de lignes de code (par exemple, le fichier qui contient le code de la fenêtre principale d'une GUI). Et assez logiquement, ce sont des fichiers qui bougent beaucoup vu que c'est là que tout le code de l'application converge. J'ai bossé sur un projet (3M de LOC) où ce genre de fichier dépasse les 30.000 LOC (200 lignes d'include...). Ce fichier reçoit une dizaine de commits par semaine (+60 développeurs). Si tu imposes C++98 sur ce fichier qui est tout en bas du graphe de dépendances (un des tout premier fichier de l'application ville de 15 ans!), tu imposes C++98 sur tous les autres fichiers et modules qui sont inclus (c'est à dire les 3/4 de l'application). A l'inverse, si tu imposes un niveau de qualité moderne sur ce fichier vieux de 15 ans, eh bien, explique à ton manage que tu ne vas plus rien produire d'autre que des régressions pour l'année qui vient.

C'est ça le legacy : un mélange de styles et de versions dans un même fichier. Il y a des parties qu'on fait évoluer quand le besoin s'en fait ressentir, et le reste, on n'y touche pas. Et c'est valable dans tous les autres langages : on ne compile par telle méthode en Php 4 et telle autre en Php 7.

La gestion des versions est quelque chose qui ne relève pas du langage mais de la méthodologie de travail. Ca se gère avec des outils adaptés (build système, package manager...), des processus rigoureux (automatisation complète de toute sa toolchain, traçabilité des 3rd parties...) et de la formation/communication interne. Et ça a finalement assez peu à voir avec le langage utilisé.

La position du comité C++ est d'encourager la migration automatique de code vers les normes les plus récentes. Du coup C++ dispose depuis des années d'un tel outil, efficace et gratuit. Tous les autres langages ne peuvent pas en dire autant.

Un dernier point est que l’adoption par l'industrie des nouvelles normes C++ est très rapide. Là encore tous les langages popuilaires ne peuvent pas en dire autant (python...). Certains langages se sont même bien vautré là dessus (perl...). C'est un élément factuel qui montre que le comité de normalisation C++, dans l'ensemble, et compte tenu des énormes défis soulevés, fait du bon travail. Après les critiques constructives sont les bienvenues sur leur liste de discussion.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

C'est à ce genre d'outil qu'incombe la gestion de versions et autres options de compilation par fichier, pas au langage.

---

Stricto sensu, ce qui existe actuellement, c'est pas unité de compilation pas par fichier. Mais je pense que dans le contexte c'est bien de ça que tu voulais parler.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Mais si tu tiens absolument à gérer ça dans le code, c'est techniquement possible depuis longtemps via le préprocesseur, et c'est plus un truc qu'on fait quand on a vraiment pas le choix (période de transition) car c'est très dommageable pour la lisibilité du code.

---

Je veux bien un exemple.
Car je vois très bien comment il est possible, via le préprocesseur, d'avoir des variantes du code en fonction de la norme utilisée, voire de supprimer du code dans certaines versions [1]. Mais je ne vois comment tu peux dans un même fichier avec une unique implémentation de chaque fonction (ou classe ou autre) et de dire cette fonction est en C++X et celle là en C++Y.
C'est ce que propose stardeath.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Tout simplement parce qu'un code écrit dans une vielle version du langage et un autre dans une version récente, dans la vraie vie, ça n'existe pas. Le nouveau code se greffe par dessus l'ancien : ça commence par un fichier de 2000 lignes écrits en C++98, puis on ajoute/modifie 1000 lignes en C++11, 500 en C++14, 200 en C++17 au fil des années. Et ce que tu veux absolument éviter c'est :
- figer un code dans une version précise de C++ : cela condamne ton code à la mort et te met en danger vis à vis de ton écosystème qui va cesser de supporter cette version à un moment donné (lib tierces...)
- devoir mettre à niveau 2000 lignes de C++98 (avec impact sur le code qui en dépend...) avant de pouvoir rajouter une seule ligne plus moderne dans un fichier existant

Aussi, techniquement parlant, passé un certaine taille / un certain nombre de dépendances, il est risqué voire impossible de mélanger du code compilé dans des modes différents (l'ABI de C++ n'est pas stable). Pour rappel les types aussi courant que std::string changent d'une version de compilo à l'autre et ne peuvent donc pas être mélangées. Qui plus est, recompiler son vieux code en mode récent apporte des gains de perf qui peuvent être significatifs (la move semantic dans la STL a d'ailleurs été conçue pour ça: augmenter les perfs de ton code legacy sans avoir à le retoucher).

---

Juste deux remarques :

• Il est aussi possible de normaliser et de fixer l'ABI (il me semble même qu'il y a eu des demandes dans ce sens.
• Un compilateur donné devrait pouvoir compiler des codes dans des versions de norme différentes en ayant une même ABI et en gérant ce qu'il y a à gérer. D'ailleurs à ma connaissance, les ruptures de compatibilité d'ABI dans g++ le sont entre versions de g++ indépendamment de la version du C++ ciblée (quand l'ABI casse, elle casse quelque soit la version du C++ ciblé).

Il reste le problème des contraintes d'implémentation par le norme contradictoire entre version. Mais à froid je n'en vois pas. Je vois seulement des interdictions par des versions récentes d'implémentations autorisées avant (format des entiers signé, non contigüité des chaînes, etc.), mais il existe à chaque fois des implémentations conformes aux deux. Si tu as des contre-exemples je suis preneur.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Typiquement, chaque gros projet va avoir quelques fichiers qui centralisent une grosse partie de l'application et dépassent l'entendement en terme de lignes de code (par exemple, le fichier qui contient le code de la fenêtre principale d'une GUI). Et assez logiquement, ce sont des fichiers qui bougent beaucoup vu que c'est là que tout le code de l'application converge. J'ai bossé sur un projet (3M de LOC) où ce genre de fichier dépasse les 30.000 LOC (200 lignes d'include...). Ce fichier reçoit une dizaine de commits par semaine (+60 développeurs). Si tu imposes C++98 sur ce fichier qui est tout en bas du graphe de dépendances (un des tout premier fichier de l'application ville de 15 ans!), tu imposes C++98 sur tous les autres fichiers et modules qui sont inclus (c'est à dire les 3/4 de l'application). A l'inverse, si tu imposes un niveau de qualité moderne sur ce fichier vieux de 15 ans, eh bien, explique à ton manage que tu ne vas plus rien produire d'autre que des régressions pour l'année qui vient.

---

Justement, la proposition de stardeath c'est de n'imposer ni l'un ni l'autre. Mais de mettre en place des mécanismes pour indiquer dans quelle version se trouve l'élément courant plutôt que de faire supporter des constructions anciennes par des versions récentes de la norme. Avec une telle proposition tu pourrais bel et bien avoir du code de versions différentes dans un même fichier.

Autant je ne suis pas convaincu de la faisabilité et surtout du gain de son idée dans l'état actuel du langage (voir mes commentaires précédents), autant là je pense que tu lui fais un faux procès.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

La gestion des versions est quelque chose qui ne relève pas du langage mais de la méthodologie de travail. Ca se gère avec des outils adaptés (build système, package manager...), des processus rigoureux (automatisation complète de toute sa toolchain, traçabilité des 3rd parties...) et de la formation/communication interne.

---

Dans le principe, oui. Toutefois le langage peut encourager ou décourager certaines choses. Mais surtout un support minimal par le langage peut être nécessaire pour mettre en place certains outils (regarde les possibilités de refactoring que proposent les IDE de certains langage et le peu que propose les EDI C++).

Citation:

---

Envoyé par Aurelien.Regat-Barrel

La position du comité C++ est d'encourager la migration automatique de code vers les normes les plus récentes. Du coup C++ dispose depuis des années d'un tel outil, efficace et gratuit. Tous les autres langages ne peuvent pas en dire autant.

---

J'ai un peu l'impression que cette phrase contredit un peu le propos précédent puisque tu semble faire le lien entre l'existence de cet outil (Clang-tidy ou Clang-modernize je suppose) et les volontés du comité.
Alors qu'il n'y a pas de lien direct entre les deux à ma connaissance, si ce n'est le souhait de migrer vers des versions récentes et une volonté de rendre le C++ plus accessible. C'est typiquement un cas où des choix de normalisation et des positions des normalisateurs encouragent des pratiques.

Après je mettrais quand même quelques bémols. D'une part, ces outils sont certes plutôt efficaces et fort utiles [2] mais ils ne ciblent que certains points et n'en adressent quelques uns que de manière partielle. Et ça ne devrait pas changer (je doute qu'ils soient d'une grande aide pour l'introduction des concepts ou de contrats). D'autre part il existe pas mal de choses similaires dans d'autres langage (python 2to3, les capacités de refactoring des IDE), certes parfois avec une efficacité discutable.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Un dernier point est que l’adoption par l'industrie des nouvelles normes C++ est très rapide.

---

Je pense que tu extrapoles ton cas (entreprise, domaine d'activité, ou autre) un poil rapidement.
De ce que je vois dans mon contexte (qui est tout aussi limité que le tien) ce n'est pas aussi vrai. Ce que je constate c'est surtout : une forte disparité entre les sociétés (voire entre équipes au sein d'une même société), un support variable, notamment de C++17, selon les compilateurs (https://en.cppreference.com/w/cpp/compiler_support, et oui C++ builder est encore utilisé) et la présence de version encore ancienne de compilateurs (p.ex. GCC4 voire 3) dans les SDK officiels de certaines cibles embarquées, des projets importants et populaires, y compris libre, qui ont trainé à prendre en compte certains changements (voir l'exemple des auto_ptr de Boost cité par Pyramidev, ou les choix de Qt).

Bref, j'ai quand même l'impression que cette rapide adoption des nouvelles normes est extrêmement variable en fonction des domaines d'activité et des entreprises. Et que la forte visibilité de certaines grosses sociétés ou gros projets qui ont migré donne une impression générale trompeuse.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Là encore tous les langages popuilaires ne peuvent pas en dire autant (python...). Certains langages se sont même bien vautré là dessus (perl...).

---

Le cas de Perl est particulier, Perl 6 est un nouveau langage plus qu'une évolution de Perl.

Pour Python, ce qui a freiné l'adoption c'est me semble-t-il certaines grosses bibliothèques qui n'ont pas voulu migrer, choix probablement conforté par le maintient de Python 2 en vie (là encore un choix de normalisation a un impact sur les pratiques et les outils). Mais en regardant en détail, il y a eu certaines entreprises, en nombre limités certes, qui ont très vite migrer aussi et une part importante qui ont eu rapidement des bases de code hétérogènes.


[1] Et il est aussi possible de la faire tout simplement en choisissant le fichier à utiliser lors de l'édition de lien d'ailleurs.
[2] Et oui, si vous pouvez, utilisez les !

Une possibilité qui me vient à l'esprit est que, pour pouvoir utiliser une syntaxe plus moderne, le code doive se trouver dans une section syntaxe numéroVersion { ... }.

À l'intérieur de cette section, on pourrait imposer quelques changements syntaxiques, par exemple le fait que chaque fonction ne puisse avoir qu'un seul "mot-clef" parmi virtual, override et final.

Je précise que le code qui utilise les fonctions déclarée dans syntaxe numéroVersion { ... } n'a pas besoin d'être lui-même dans une section syntaxe numéroVersion { ... }. Il n'en a besoin que si lui aussi contient au moins une ligne avec une syntaxe plus moderne.

Alors, migrer tout le code d'un seul fichier (sauf la partie qui contient les #include) à l'intérieur de la section syntaxe numéroVersion { ... } ne devrait pas être très long. Il y aura toujours des développeurs qui râleront, parce qu'ils auront la flemme de migrer la moindre ligne de code. Mais il faut trouver le juste équilibre.

merci pour les réponses, mais visiblement, vu une réponse (ho combien plus constructive que "c'est pas compatible", donc merci pour tous les retours, mais visiblement il y a encore un manque de clarté de ma part, désolé) je vais essayer de prendre le temps d'écrire une propal.
même si ça sert à rien, ça sera un bon exercice.

plusieurs réponses en vrac, sans citation ;

dans ma boite actuelle, niveau version de langage, on est au c++ contenu dans visual studio 2013 et au c#5, et ça fait pratiquement 2 ans que des gens sont sur le projet de tout passer à vs2017, sûrement en best effort en plus. et dans la boite d'avant, on était condamné à gcc 4.7. je doute, vu les échos que j'ai d'anciens collègues parti à gauche et droite, qu'il y ait beaucoup de boites qui évoluent vite sur la màj du compilo donc possiblement de la version de c++.
vu que quand tu as un code, admettons, c++98, le compiler en c++11/14/17 peut t'amener des surprises ; c'est un peu pour ça aussi que je propose mon modèle, l'ancien code, reste tel quel, et tu as la possibilité d'y greffer de nouvelles parti en c++11/14/17 etc. justement pour contrer le chef qui te dirait pas de màj de la version de c++.

après pour le changement par exemple dans std::string, attention, mon but n'est pas de mélanger les différentes versions de c++ AINSI que leur stl ; si on a 2 fichiers, par exemple un en c++98 et un en c++17, on aura 2 syntaxes différentes (c++98 et 17) MAIS seulement la stl de la version 17.
c'est exactement ce qu'on a quand on change le flag -std=c++X dans gcc, on ne compile PLUS "avec la stl de la version précédente" ; ce qui donne qu'on a du vieux code, compilé avec un compilo configuré pour une version de c++ plus récente, et une stl plus à jour qu'avant.
et ça que ça soit dans le c++ actuel, ou dans ma propal, ça amène le même lot d'emmerdes.

pour l'ABI, c'est pas un problème, on est pas dans un modèle où il y aurait plusieurs étapes de compilation avec plusieurs set de flag de compil, une par langage mais une "seule" étape de compilation, avec la version de la syntaxe qui s'adapte au code en train d'être compilé.
typiquement pour le cas std::string, on aurait pas certaines parties du code compilées en pré dual abi et une partie post dual abi, mais comme je disais avant, tout compilé avec la stl la plus à jour et les mêmes flag de compil.

Citation:

---

Envoyé par stardeath

après pour le changement par exemple dans std::string, attention, mon but n'est pas de mélanger les différentes versions de c++ AINSI que leur stl ; si on a 2 fichiers, par exemple un en c++98 et un en c++17, on aura 2 syntaxes différentes (c++98 et 17) MAIS seulement la stl de la version 17.
c'est exactement ce qu'on a quand on change le flag -std=c++X dans gcc, on ne compile PLUS "avec la stl de la version précédente" ; ce qui donne qu'on a du vieux code, compilé avec un compilo configuré pour une version de c++ plus récente, et une stl plus à jour qu'avant.
et ça que ça soit dans le c++ actuel, ou dans ma propal, ça amène le même lot d'emmerdes.

---

Ah ! je n'avais compris que tu proposais ton mécanisme uniquement pour le cœur du langage et que tu n'adressais pas la bibliothèque standard [1].
Ça change pas mal les choses.

Ça laisse de côté tout un pan des changements s'opérant dans la bibliothèque standard, c'est qui est peut-être un peu regrettable mais pas bien grave puisque les cycles dépréciations/suppressions fonctionnent bien avec les bibliothèques et que la conservation sur un temps long de fonctionnalités dépréciées ajoute juste des bouts d'API inutile ce qui est sans conséquence grave [2]. Et effectivement ça n'entraine pas davantage de problèmes.

D'un autre côté, ce choix lève la plupart, si ce n'est tous, les problèmes que je voyais et rend la proposition beaucoup plus réalisable et traite les points vraiment problématiques.

Je vais devoir y réfléchir plus profondément, mais de prime abord, ça me semble être un plutôt bon compromis.



[1] Je suis parti du principe que par stl tu désignais en fait la bibliothèque standard dans son ensemble et pas uniquement la partie templatisé de celle-ci nommé historiquement STL. J'espère ne pas mettre trompé.
[2] Modulo les API retirées pour des raisons de sécurité, mais c'est un cas où il faut se faire violence et les supprimer rapidement. Toute forme de rétrocompatibilité sur ces API est un problème en soi.

quand je disais que visiblement ma propal n'était pas suffisamment claire XD

effectivement, je pense qu'on ne peut pas garder tout ce qui pourrait entraver la compatibilité au niveau code compilé.

le point suivant sera fait en ignorant la dual abi, qui a été un artifice de gcc pour pas casser les anciennes bibliothèques compilées ;
garder 2 versions de par exemple std::list ou std::string (à cause d'un changement de spec, size en O(1) pour la list et pas de copy on write pour la string), impliquerait de pouvoir automatiquement convertir "c++98 list" vers et depuis "c++17 list", et là ça commencerait à être un bordel de wrapper et autre, le tout avec un coup d'exécution non négligeable.

le fait de ne garder qu'une seule version (la plus récente) de la bibliothèque standard est pour moi la façon la plus simple de s'éviter un paquet de problèmes, l'api de celle-ci est quand même sacrément stable, ce qui facilite la compilation d'ancien code avec une nouvelle version de c++.
reste que effectivement, on ne peut pas faire grand chose avec les changements de spec, et pareil, j'ai pas de magie à proposer la dessus avec ma propal.

ps: j'ai pas répondu à ta question, je m'adresse plutôt au cœur du langage, pas que la bibliothèque standard ne m'intéresse pas, je pense que c'est moins (voir pas du tout) problématique.

Je ne suis pas en faveur du mélange de code de plusieurs versions du C++ à grains fins dans le même projet, pour plusieurs raisons :
- Déjà, celle expliquées par Aurélien qui font que ça aurait un mauvais impact sur l'évolution du code
- Ensuite à cause de la difficulté énorme pour un développeur qui devrait à chaque instant maîtriser non pas 1 version de la norme (le sous ensemble commun mis en oeuvre par ses compilateurs actuels), mais plusieurs en même temps
- Finalement, je pense que comme les différences vont bien au délà de la syntaxe, il va y avoir plein de problème aux interfaces... Quelques exemples sans vraiment réfléchir profondément :
- Un fonction C98 prend un argument par valeur. Je l'appelle dans un contexte C++11 avec un temporaire. Ce dernier doit-il être copié (sémentique C++98) ou déplacé (sémentique C++11) ?
- Ai-je le droit de faire dans un code C++11 un memcpy d'un objet défini en C++98 qui n'est pas un POD mais est triviallement copiable ?
- Deux séquences de token identiques sont-elles ODR-equivalent si elles ne sont pas dans la même version de la norme ?
- Est-ce que je peux instantier un template C++98 avec un argument C++17 ? Quelle version de la norme sera utilisée pour interpréter le code résultant de cette instantiation ? Si on dit C++98, il risque d'y avoir plein de truc étranges dans l'argument que le compilateur ne comprendra pas. Si on dit C++17, on risque d'avoir des soucis si le code C++98 n'est plus considéré comme valide justement parce que le but de cette mécanique est de pouvoir ne plus le considérer comme valide...
- Même question en remplaçant "template" par "macro"...
- Et je ne fais probablement qu'effleurer la surface...

Dit autrement, je pense que ça pourrait peut-être marcher au niveau syntaxique et code généré, mais j'ai du mal à voir ce que ça pourrait donner au niveau préprocesseur et surtout sémantique...