Version imprimable
ok, c'est mieux. C'est pas ce qui avait été dit à la base.Citation:
Je ne parle de compiler du js, mais de faire de la transpilation
Je suis pas trop pour la transpilation, problématique pour une recherche de bug par exemple si on connait pas le langage, surtout que c'est pas un langage difficile quand on sait coder.
La dernière norme est sortie en 2020 et est C++20.Citation:
Envoyé par chrtophe
C++23 est en discussion depuis un moment maintenant.
Et quand elle sera sortie, les échanges pour C++26 commenceront.
Je parlais du Cobol Bousk.
C'est dommage, tu étais crédible sur la première moitié de ton commentaire et tu t'es suicidé dès que tu as parlé de C++.Citation:
Envoyé par Fleur en plastique
Le C++ moderne est une aberration inventée dans un Bureau De Complication Des Affaires Simples.
Le pire c'est que ses fanatiques se prennent pour une sorte d'élite intellectuelle des codeurs.
Personnellement ma tête me sert à résoudre des problèmes complexes, pas à écrire dans un langage pourri le même code de débile qu'on lit partout.
Oui, shenron666, tu as le droit de penser que je suis suicidaire :ptdr:
Ah pardon, je ne savais pas môsieur était de la "Haute"
j'invite humblement môsieur à signaler à Epic Games que le Unreal Engine est écrit dans un langage pourri
et qu'ils devraient faire appel à la tête de môsieur pour écrire autre chose que ce qu'on lit partout
môsieur devrait faire de même avec Google étant donné que TensorFlow est aussi écrit dans le langage qui ne sied guère à môsieur
sans prétention, une petite liste pour aider môsieur dans sa décadence
https://github.com/EvanLi/Github-Ran.../Top100/CPP.md
Ne compare pas les cadors qui ont fait UE5 avec le fanboy C++ moyen, qui code comme Chat GPT (Ou plutôt c'est Chat GPT et ses amis qui remixent du code écrit par des codeurs moyens)
Et puis UE5 aurait gagné à être écrit en C. Ce vieux langage tellement "bête" que le code est basiquement maintenable... Franchement le C++ c'est génial ! Pour éviter au programmeur de faire une gestion manuelle de la mémoire en permanence... ils ont inventé quelque chose de plus compliqué que la gestion manuelle de la mémoire. Pour faire du polymorphisme et de la généricité en C, on avait les void*, les pointeurs de fonctions et les casts sauvages (ouh la la, c'est pas bien, parce que si on fait n'importe quoi, le compilateur n'y voit que du feu... ébé arrête de faire n'importe quoi, tout simplement, non ?). En C++ on a plus compliqué pour faire... pas mieux. Etc.
Bon après quand tout le monde aime un langage de m.... dans lequel il n'y a rien qui va, les trois pingouins qui voient un peu plus clairs que les autres ont un avantage sur la concurrence :ptdr:
Mais chacun fait comme il l'entend.
Les évolutions, il faut s'en servir si on en a besoin, ou qu'on les a compris, sinon c'est effectivement une complication.Citation:
Le C++ moderne est une aberration inventée dans un Bureau De Complication Des Affaires Simples.
Rien ne t’empêche d'écrire un code simple en C++ sans utiliser de fonctionnalités complexes. Mais il faut garder à l'esprit que ces fonctionnalités apportent un plus, après pas forcément pour tes cas de figure.
Bonjour,
J'aime bien le C++ mais je regrette l'empilage que chaque version amène. Parti d'un langage squelettique, il est devenu verbeux. Les transtypages en sont un exemple.
Le multi paradigme est une course en avant qui tend à retirer de la cohérence au langage. Par exemple, comment concilier un typage plus fort avec auto ?
Certains ajouts semblent juste là pour la beauté intellectuelle. Est-ce que la métaprogrammation a vraiment un intérêt pratique ?
Je trouve qu'un langage qui multiplie les éléments de contrôle du compilateur - les expressions déclarées constantes par exemple - tend à faire un grand écart entre abstraction et bas niveau. Les directives de compilation sont normalement extrinsèques au langage. Intégrer de plus en plus de mots clés ou de formes particulières (déclaration des strings par exemple) dédiés à ce contrôle me semble mélanger indument deux mondes.
Bien sûr on peut se contenter de n'utiliser qu'une partie des fonctionnalités mais comment bien choisir sans tout connaître et comprendre ?
Je rêve d'une version d'apurement qui redonne au C++ une personnalité propre au lieu de le laisser devenir seulement un collector.
Mais cela n'engage que moi, et encore... :D
Salutations
Je ne pense pas que le transtypage ait bougé depuis 20 ans. Les plus difficiles à comprendre sont liés aux convertions des scalars. Convertions hérités du C. Les autres sont plutôt explicites et contrôlables par l'utilisateur (via constructeur ou l'opérateur de conversion: operator T ()). En fait, le seul ajout un peu lié a été fait il y a 10 avec initializer_list, qui — bien que partant sur une bonne indentation — est assez complexe à utiliser convenablement (mais je ne suis pas certain qu'on peut appeler ça du transtypage).Citation:
Envoyé par Guesset
Le multi-paradigme, tous les langages le font à plus ou moins grande échelle. Ce n'est qu'une manière de représenter la manière dont un langage pourrait fonctionner pour adapter le point de vue le plus pratique à un problème donné. Même dans des langages qui se veulent purement fonctionnel comme Haskell, on se retrouve avec des structures mutables parce que ce n'est pas toujours la solution la plus efficace.Citation:
Envoyé par Guesset
Quant à auto, il faudra m'expliquer comment faire un typage plus "fort" que celui défini par l'expression elle-même. Si auto ne convient pas (au niveau du type), c'est que l'expression n'était de base pas dans le type voulut. C'est pas un typage dynamique, mais statique, vous ne semblez pas savoir de quoi vous parlez.
Oui. Premièrement pour la généricité. Pourquoi faire X fonction max() par type plutôt qu'une seule et unique fonction max() qui marche avec n'importe quel type (du moment que < est définit) ?Citation:
Envoyé par Guesset
Deuxièmement, et c'est le plus complexe à faire, pouvoir spécialiser les comportements pour un type spécifique ou une catégorie de type dans le but d'étendre les comportements ou de choisir un algo plus efficace.
Ce que tu appelles "des éléments de contrôle du compilateur" sont juste la séparation de 2 mondes qui existent dans le langage: runtime et compile-time. Dans certaines circonstances, on préfère avoir la garantie du compile-time pour de la vérification d'erreur à la compilation, des types dépendant de valeur ou simplement pour des raisons de performance. Quand on fait beaucoup de méta-programmation, c'est un besoin qui arrive assez vite.Citation:
Envoyé par Guesset
(Je n'ai pas compris cette histoire de déclaration des strings)
Comme avec n'importe quel langage finalement: l'expérience. Mais oui, il y a beaucoup de chose et pas mal qui devrait être supprimées / modifiées. Actuellement, les propositions sur les changements profonds sont confrontées à "stabilité d'ABI". Du coup, ce qui existe déjà est très difficilement modifiée.Citation:
Envoyé par Guesset
Bonjour,
Je ne vais pas répondre point par point aux propos de jo_link_noir. Chacun a le droit d'avoir un avis.
Mes propos visaient la tendance d'évolution du C++, pas seulement les toutes dernières.
Les conversions de type héritées du C ont changé de forme (plus lourdes) pour les homogénéiser avec une diversification des xxx_cast. Bien sûr on peut utiliser l'ancienne forme C, mais ce n'est pas recommandé.
Pour la métaprogrammation j'aurais dû être plus précis car je faisais allusion aux calculs statiques pendant la compilation et non à la généricité qui est bien pratique mais pose souvent des problèmes d'efficacité (la meilleure recette est rarement polyvalente).
Je ne sais peut être pas de quoi je parle mais je préfère qu'on m'en fasse la démonstration plutôt qu'un assertion gratuite. Quand on déduit le type d'une expression c'est beaucoup plus flou qu'une définition explicite. Par exemple 1 peut être un entier signé ou non signé, sur 1, 2, 4 ou 8 octets (voire plus si affinités).
Je parle des éléments de contrôles de compilation intégrés au langage (mots clés) et non des paramètres du compilateur. Il y en a toujours eu un peu (inline, register...) mais je pense que le nombre devrait en être le plus limité possible (séparer si possible le comment du quoi limite les effets de portabilité).
On peut pratiquement tout faire avec n'importe quel langage qui génère du code natif. Le vieux C le montre tous les jours. La différence n'est donc pas la polyvalence mais la facilité et la fiabilité offertes par tel ou tel langage ou ses améliorations. Mais la multiplicité de ces dernières peut conduire à un accroissement de complexité du langage ce qui est contradictoire.
Mais je ne cherche à convaincre personne. Quand un langage me paraît moins pratique qu'un autre pour un besoin donné, j'en change.
Salutations
Ok, vous parliez des conversions explicites, je faisais référence aux conversions implicites. Le but premier étant d'être visible et mettre plus de sécurité (vs un cast qui fait tout et n'importe), je trouve que ça joue parfaitement le rôle.
Oui est non. Le type est n'est pas forcément une information utile et il peut être indiqué dans l’expression (ce qui en fait une information redondante). Du coup je ne comprends pas, vous reprochez à auto de déduire un type qui n'est pas celui voulut... Par conséquent, vous lui reprochez de ne pas faire de conversion ? Auto n'est pas fait pour ça, si le type est important, c'est normal de le mettre explicitement.Citation:
Quand on déduit le type d'une expression c'est beaucoup plus flou qu'une définition explicite. Par exemple 1 peut être un entier signé ou non signé, sur 1, 2, 4 ou 8 octets (voire plus si affinités).
Pour les mots clefs, je ne comprends toujours pas. La plupart font référence à la visibilité des symboles et aux lifetimes. Je ne vois pas le rapport avec le fait d'avoir des expressions constantes. « Éléments de contrôles de compilation » ne me parle pas du tout. Mais sinon, la norme indique le quoi, rarement le comment. De quel effet de portabilité parlez-vous ?
À partir du moment où l'on veut ajouter de la sémantique et de la sécurité, je pense qu'on est obligé de définir plus de concept. Mais à mon avis, l'erreur est de considérer qu'ils doivent être tous connue pour faire les choses convenablement. Un langage qui se complexifie, n'est pas forcément un langage plus complexe.Citation:
On peut pratiquement tout faire avec n'importe quel langage qui génère du code natif. Le vieux C le montre tous les jours. La différence n'est donc pas la polyvalence mais la facilité et la fiabilité offertes par tel ou tel langage ou ses améliorations. Mais la multiplicité de ces dernières peut conduire à un accroissement de complexité du langage ce qui est contradictoire.
Le "vous ne semblez pas savoir de quoi vous parlez" de jo vient de la première partie du message.Citation:
Envoyé par Guesset
Une variable déclarée avec auto a un type fixé, à la compilation, qui ne change pas pendant toute la durée de sa portée et permet les mêmes vérifications du compilateur qu'un type explicite. En cela, ça n'affaiblit pas du tout le typage fort du C++.
A la rigueur, tu aurais pu parlé de any ou variant (qui eux, effectivement, affaiblissent le typage fort) mais cette faiblesse n'est pas une nouveauté des nouvelles versions du C++. L'utilisation de void* (qui vient du C, donc présent dès l'origine du C++) est une faiblesse dans le typage fort du C++. Any et variant sont des renforcements du typage par rapport a void*.
L'association "typage fort" et "auto" n'a pas de sens.
Pareil pour "multi paradigme". La typage fort et auto n'ont rien à voir, ni l'un ni l'autre, avec les paradigmes. (A la rigueur auto pour le paradigme générique, mais pareil, c'est pas une nouveauté apportée par auto, le C++ supportait déjà le paradigme générique avec les templates).
Que tu trouves auto plus "flou" qu'un typage explicite, je peux le comprendre. Mais cela n'a rien a voir pour le coup avec le typage fort et le multi paradigme. (Et ce n'est pas une spécificité du C++, beaucoup de langages ont des typages non explicites. Et on peut aussi considérer que les templates sont une forme de typage non explicite)
Sauf que ce que tu critiques (meta programmation, cast, multi paradigme, etc) sont des choses qui existent depuis la première standardisation du C++. Un C++ qui n'aurait pas ce que tu décris, ça n'a jamais existé (au mieux, ca serait le C with class).Citation:
Envoyé par Guesset
Alors, bien sur que les évolutions d'un langage apportent des complexités nouvelles à apprendre. Au même titre que le C++ est plus compliqué a apprendre que le C. Mais cette complexité apporte plus de possibilités et de simplicités aux devs.
Contrairement à ce que dit Jamatronic, "arrête de faire n'importe quoi" n'a jamais marché pour améliorer la qualité des logiciels. Ce qui marche, c'est toutes les vérifications automatiques, en particulier celles faites par le compilateur. Cette complexité du langage, c'est plus de possibilité pour les devs d'exprimer ce qu'ils souhaitent et de permettre au compilateur de vérifier si le code correspond à ce que le dev cherche a faire. const n'est qu'un moyen de dire au compilateur "je pense que la valeur de cette variable ne change pas" et le compilateur va pouvoir vérifier si c'est correct. Les cast permettent d'exprimer différents types de conversion (ce que ne permet pas le cast en C, c'est un cast qui fait plusieurs choses différentes) et le compilateur va pouvoir vérifier si c'est une conversion conforme au type de cast souhaité.
En pratique, sur des gros projets pro, cette complexité des ajouts récents du C++, ce n'est pas du temps perdu à l'apprentissage et l'utilisation, mais du temps gagné du l'ensemble du temps de vie d'un logiciel.