S’il y a effectivement du code qui peut être cassé à chaque évolution du langage, on est très loin de ce que tu décris et de la fréquence que tu sembles indiquer.
Les évolutions du langage, c'est tous les 2 ou 3 ans. Et ça m'arrive très souvent de passer du temps à rebricoler des trucs pour compiler du vieux code, simplement parce que les compilateurs corrigent des bugs d'implémentation de la norme (des trucs qui émettaient un warning et qui donnent une erreur, des syntaxes illicites qui passaient mais qui ne passent plus). Évidemment, pour un projet à soi, on s'en fout (une demi-journée tous les trois ans, ça n'est pas la mer à boire), mais pour l'ensemble de l'écosystème, c'est juste chiant. Et du coup, l'idée de compiler du vieux code non-trivial sans mettre les mains dans le cambouis, ça ne fonctionne pas. Alors un truc dégueu (genre goto) qui devient déprécié, ça gène qui exactement? Surtout que tu pourrais avoir une option du compilo pour dire "compile-moi ça quand même".
Le problème, c'est que C++ ne veut pas choisir entre la rétrocompatibilité C et le C with classes d'un côté, et un langage objet moderne de l'autre côté. Est-ce qu'on peut promouvoir indéfiniment ce modèle chimérique? Ça intéresse qui exactement de pouvoir faire un printf avec un argument template? Évidemment, tu peux lire des bouquins, des guidelines, des tutoriels, mais si le langage te transmets l'idée qu'il y a 75 manières de faire quelque chose et qu'il est neutre à ce sujet, il y a un problème. Si la cohérence du language tient au respect de quelques bonnes pratiques qui ne sont pas implémentées par défaut, alors il y a un problème (par exemple, pourquoi les destructeurs ne sont-ils pas virtuels par défaut?).
Sur le fond, la question n'est pas sur la complexité de certaines techniques très poussées qui ne servent qu'à une toute petite fraction des développeurs. C'est peut-être cool de pouvoir surcharger "new" ou "*", personnellement je m'en fous. Par contre, il est anormal que cette souplesse s'accompagne de bizarreries historiques portant sur du code complètement courant (typiquement, les arguments de main), des syntaxes WTF, ou des subtilités pédantesques (personnellement, j'aime bien le comportement d'un bool qu'on a oublié d'initialiser).
[^] # Re: Donc pour résumer...
Posté par arnaudus . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 5.
Les évolutions du langage, c'est tous les 2 ou 3 ans. Et ça m'arrive très souvent de passer du temps à rebricoler des trucs pour compiler du vieux code, simplement parce que les compilateurs corrigent des bugs d'implémentation de la norme (des trucs qui émettaient un warning et qui donnent une erreur, des syntaxes illicites qui passaient mais qui ne passent plus). Évidemment, pour un projet à soi, on s'en fout (une demi-journée tous les trois ans, ça n'est pas la mer à boire), mais pour l'ensemble de l'écosystème, c'est juste chiant. Et du coup, l'idée de compiler du vieux code non-trivial sans mettre les mains dans le cambouis, ça ne fonctionne pas. Alors un truc dégueu (genre goto) qui devient déprécié, ça gène qui exactement? Surtout que tu pourrais avoir une option du compilo pour dire "compile-moi ça quand même".
Le problème, c'est que C++ ne veut pas choisir entre la rétrocompatibilité C et le C with classes d'un côté, et un langage objet moderne de l'autre côté. Est-ce qu'on peut promouvoir indéfiniment ce modèle chimérique? Ça intéresse qui exactement de pouvoir faire un printf avec un argument template? Évidemment, tu peux lire des bouquins, des guidelines, des tutoriels, mais si le langage te transmets l'idée qu'il y a 75 manières de faire quelque chose et qu'il est neutre à ce sujet, il y a un problème. Si la cohérence du language tient au respect de quelques bonnes pratiques qui ne sont pas implémentées par défaut, alors il y a un problème (par exemple, pourquoi les destructeurs ne sont-ils pas virtuels par défaut?).
Sur le fond, la question n'est pas sur la complexité de certaines techniques très poussées qui ne servent qu'à une toute petite fraction des développeurs. C'est peut-être cool de pouvoir surcharger "new" ou "*", personnellement je m'en fous. Par contre, il est anormal que cette souplesse s'accompagne de bizarreries historiques portant sur du code complètement courant (typiquement, les arguments de main), des syntaxes WTF, ou des subtilités pédantesques (personnellement, j'aime bien le comportement d'un bool qu'on a oublié d'initialiser).