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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Normalisation C++ Discussion :

Cppfront, la proposition de nouvelle syntaxe C++ par Herb Sutter, anime les débats entre développeurs


Sujet :

Normalisation C++

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    février 2017
    Messages
    1 520
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 1 520
    Points : 44 462
    Points
    44 462
    Par défaut Cppfront, la proposition de nouvelle syntaxe C++ par Herb Sutter, anime les débats entre développeurs
    Cppfront, la proposition de nouvelle syntaxe C++ par Herb Sutter, anime les débats entre développeurs sur les besoins en termes d’évolution du langage
    Et les comparaisons avec des projets similaires

    Cppfront c’est déjà 5 ans de travail dans l’ombre. C’est un projet personnel de Herb Sutter avec un objectif qui se résume en une phrase simple : proposer une évolution du C++ à la syntaxe dix fois plus simple que l’actuelle, plus sûre et avec le même niveau de support d’outils dont bénéficient les autres langages. Le directeur du comité de normalisation ISO C++ ouvre à peine le projet au public que celui-ci anime déjà les débats entre développeurs sur leurs attentes en matière d’évolution du langage désormais considéré par plusieurs comme une usine à gaz. L’initiative ne manque non plus de susciter les comparaisons avec des projets aux visées similaires.

    En langage C++, A * b peut soit faire référence à une opération sur les pointeurs, soit à une multiplication. Cette seule remarque signifie pour un développeur que pour la mise sur pied d’un linter ou d’un outil de formatage de code en C++ il faudra analyser l’ensemble du code pour parvenir à construire un arbre d’analyse correct. C’est un exemple parmi une multitude pour illustrer la complexité du langage. C’est à ce type de problématiques auxquelles Cppfront vient s’attaquer. La documentation du projet n’est pas encore disponible. Une section exemples l’est néanmoins et permet déjà de se faire une idée des évolutions envisagées. On pourra observer que Cppfront se passe des #include.

    Nom : 1.jpg
Affichages : 60867
Taille : 16,1 Ko

    Nom : 2.jpg
Affichages : 6980
Taille : 30,1 Ko

    Cppfront comme son nom l’indique se veut être un frontend à partir duquel la syntaxe en cours de gestation sera transformée en du C++20.

    Nom : 0.png
Affichages : 6967
Taille : 105,3 Ko


    Cppfront n’est pas sans faire penser au projet Carbon positionné comme successeur expérimental du C++. L’objectif : explorer une direction future possible pour le C++ étant donné les difficultés à l’améliorer. Carbon est un nouveau langage qui vise à égaler les performances de C++ et à maintenir une interopérabilité bidirectionnelle transparente, ainsi qu'une courbe d'apprentissage douce pour les développeurs C++.

    L'équipe promet en sus un certain niveau de traduction de source à source pour le code C++. Le projet présente des parallèles avec TypeScript pour les développeurs JavaScript, ou Kotlin pour les développeurs Java, bien que la comparaison ne soit pas exacte. Carbon est conçu pour être interopérable avec le code C++ et pour faciliter la migration. La chaîne d'outils Carbon prendra en charge la compilation du code C++.

    Selon l'équipe Carbon, les concepteurs du C++ ont ajouté plutôt que remplacé des fonctionnalités du langage au fil du temps, créant ainsi des interactions complexes entre les fonctionnalités. La préservation de la compatibilité binaire est un autre problème hérité. En outre, le comité C++ et le processus d'évolution sont orientés vers la normalisation plutôt que la conception, sont lents et ne parviennent pas toujours à prendre des décisions.

    Carbon s'efforce de contourner ces problèmes en adoptant une nouvelle approche fondée sur les principes de l'open source : « Nous tenterons même de combler une énorme lacune dans l'écosystème C++ avec un gestionnaire de paquets intégré ». La feuille de route actuelle vise à terminer la version 0.1 du langage cette année, la 0.2 en 2023 et la version 1.0 en 2024 ou 2025.

    Le langage Carbon sera familier aux développeurs C++ et C, mais il y a aussi de nombreuses différences. Les fonctions sont déclarées avec le mot clé fn et les variables avec var. Il existe également des tuples fortement typés. L'inférence de type est supportée par le mot-clé auto. Les pointeurs sont pris en charge mais pas l'arithmétique des pointeurs ; les seules opérations sur les pointeurs sont l'adressage et le déréférencement. Les classes supportent l'héritage simple mais pas l'héritage multiple.

    Nom : 4.png
Affichages : 6931
Taille : 44,6 Ko

    Cppfront et Carbon sont des exemples d’une longue liste dans laquelle on retrouve d’autres initiatives comme Circle, Val et Dlang.



    Source : cppfront, Herb Sutter

    Et vous ?

    Êtes-vous développeur C++ ? Quelle plus-value reconnaissez-vous à ces différents projets ? Sinon qu’en attendez-vous ?
    Ces projets viennent-ils avec une plus-value véritable en comparaison à un langage comme le Rust considéré le futur pour ce qui est du développement d’applications système ?

    Voir aussi :

    Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

    Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

    Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

    Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre actif
    Homme Profil pro
    Consultant informatique
    Inscrit en
    février 2014
    Messages
    46
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : février 2014
    Messages : 46
    Points : 220
    Points
    220
    Par défaut
    C'est marrant comme on aime critiquer la syntaxe du C et C++, alors que moi personnellement de tout les langages que j'ai pu faire c'est l'une de celle que je préfère.

  3. #3
    Membre chevronné Avatar de onilink_
    Profil pro
    Inscrit en
    juillet 2010
    Messages
    529
    Détails du profil
    Informations personnelles :
    Âge : 31
    Localisation : France

    Informations forums :
    Inscription : juillet 2010
    Messages : 529
    Points : 2 192
    Points
    2 192
    Par défaut
    @SimonKenoby
    Ici la critique adresse plus la difficulté de parser la syntaxe (qui est très contextuelle).


    Bien que je déteste la syntaxe proposée (je la trouve difficile à lire et à écrire), l'idée de faire un frontend pour avoir une syntaxe bien plus simple à parser/traiter est très intéressante.

    Maintenant en tant que développeur qui veut parser du C++, est ce qu'il ne serait pas plus simple de directement utiliser le "Clang Code Model"...?
    De ce que j'ai pu voir, les IDE qui ont une bonne prise en charge des outils de refactoring, coloration etc... utilisent ça (Qt Creator par ex).
    Circuits intégrés mis à nu: https://twitter.com/TICS_Game

  4. #4
    Membre averti Avatar de BakaOnigiri
    Inscrit en
    avril 2002
    Messages
    366
    Détails du profil
    Informations forums :
    Inscription : avril 2002
    Messages : 366
    Points : 425
    Points
    425
    Par défaut
    C'est marrant, pour un article qui doit nous présenter Cppfront, 50% présente Carbon

  5. #5
    Expert éminent sénior

    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    avril 2002
    Messages
    2 672
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Finance

    Informations forums :
    Inscription : avril 2002
    Messages : 2 672
    Points : 18 052
    Points
    18 052
    Par défaut
    Citation Envoyé par BakaOnigiri Voir le message
    C'est marrant, pour un article qui doit nous présenter Cppfront, 50% présente Carbon
    Certes, mais si tu veux plus de détails sur Cppfront tu peux toujours aller voir la source, le fait d'ajouter Carbon dans l'article est très pertinent pour comparer et élargir la problématique générale, c'est donc purement une valeur ajoutée de l'article, et en fait la vidéo proposée dans l'article est très intéressante à cet égard
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  6. #6
    Expert confirmé

    Profil pro
    Inscrit en
    février 2006
    Messages
    2 360
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 2 360
    Points : 4 664
    Points
    4 664
    Par défaut
    la dernière fois où j'ai participé à une discussion ici sur la syntaxe du c++, ça c'est plutôt mal passé, les participants ne voyant pas les problèmes de cette "magnifique" syntaxe, je ne suis pas sur que ça ait beaucoup changé entre temps.

    ou alors peut être que, parce que c'est Sutter (entre autres) qui avance un mouvement, on commencera peut être à voir les problèmes ...

    le comité, faudra que je retrouve le texte, ne voulait pas entendre parler de révision du langage, craignant l'apparition de dialectes du c++.
    à force de ne jamais retenir une solution cohérente à un même problème et de superposer des couches pour garder une relative compatibilité (et encore) de syntaxe (et surtout garder des vestiges du c, qui lui ne se prive pas de tout casser), on en arrive à avoir des constructions alambiquées parce que "on ne veut rien casser, enfin sauf des fois, ça dépendra de la chance et du sens du vent".

  7. #7
    Membre averti Avatar de BakaOnigiri
    Inscrit en
    avril 2002
    Messages
    366
    Détails du profil
    Informations forums :
    Inscription : avril 2002
    Messages : 366
    Points : 425
    Points
    425
    Par défaut
    Citation Envoyé par Pierre Louis Chevalier Voir le message
    Certes, mais si tu veux plus de détails sur Cppfront tu peux toujours aller voir la source, le fait d'ajouter Carbon dans l'article est très pertinent pour comparer et élargir la problématique générale, c'est donc purement une valeur ajoutée de l'article, et en fait la vidéo proposée dans l'article est très intéressante à cet égard

    Peut être, sauf que si j'ai tout bien compris, Carbon serait plus un nouveau langage (au même titre que Go, Rust, ...) mais avec une grande compatibilité C++ (lors de la phase d'édition de liens), alors que Cppfront sera transcodé en C++20 (tout comme Typescript qui deviens du JS), donc même si cela ressemble à un nouveau langage, cela n'est que "juste" une surcouche.

    Bon, et maintenant je me demande comment un décrit un langage de programmation, Typescript et Cppfront qui sont une autre manière de décrire du code et qui deviennent un autre code avant la phase de compilation sont-ils des langages de programmations ? Hum ... bon cela semble évident que oui, mais je fait tout de même une distinction entre ces 2 outils et Carbon, Go, Rust ...

  8. #8
    Expert éminent sénior

    Homme Profil pro
    Directeur des systèmes d'information
    Inscrit en
    avril 2002
    Messages
    2 672
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 62
    Localisation : Luxembourg

    Informations professionnelles :
    Activité : Directeur des systèmes d'information
    Secteur : Finance

    Informations forums :
    Inscription : avril 2002
    Messages : 2 672
    Points : 18 052
    Points
    18 052
    Par défaut
    Citation Envoyé par BakaOnigiri Voir le message
    Peut être, sauf que si j'ai tout bien compris, Carbon serait plus un nouveau langage (au même titre que Go, Rust, ...) mais avec une grande compatibilité C++ (lors de la phase d'édition de liens), alors que Cppfront sera transcodé en C++20 (tout comme Typescript qui deviens du JS), donc même si cela ressemble à un nouveau langage, cela n'est que "juste" une surcouche.
    C'est des solutions différentes mais c'est pour répondre à la même problématique, à savoir l'avenir du C++, et ça fait débat, aussi bien sur les communautés US qu'ici.
    Ne prenez pas la vie au sérieux, vous n'en sortirez pas vivant ...

  9. #9
    Membre habitué
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    mai 2015
    Messages
    24
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : mai 2015
    Messages : 24
    Points : 173
    Points
    173
    Par défaut SI ce n'était pas herb sutter...
    ...je n'aurais même pas pris la peine de lire ce post. Et je suis déçu de l'avoir lu
    Le C reste et restera la référence pour quelques temps encore. Le C++, j'y ai tâté lorsque j'étais jeune, mais qd je suis tombé sur le livre d'un certains "Andreisecsu" (pas sûre du nom), de 700 pages, rien que pour aborder les "templates", j'ai stoppé net "l'étude" de ce langage, dont seule la possibilité de faire de la POO (par rapport au C classique) m'intéressait (et c'était il y a 25 ans, je n'ose imaginer ce que tout ce brol est devenu...).

    • Lorsque je veux faire simple, je le fait en Python + wxPython.
    • Le C, c'est pour l'embarqué ou des petits émulateurs pour des petits/vieux processeur ou autre matériel basé dessus.
    • Le Rust, j'avoue ne pas encore avoir regarder, je ne parlerais donc pas de ce que je ne connais pas.
    • Le C++ est vite illisible (mon mantra : On écrit 1x on lit 100x le même code), donc j'ai laissé tomber.
    • J'ai regardé à Haxe, pour faire des jeux, qui est un transpilateur, et le debug est juste horrible, comme tout ce qui n'est pas "natif". Enfin, c'était Il y a 5 ans, de bonne chose sont peut-être arrivées depuis. A revoir donc.


    Pour en revenir à ce "nouveau" C++ (ce n'est pas le premier, java était déjà une tentative, mais est encore pire), le temps qu'il soit soit au point, normalisé, popularisé, je serais 6 pieds sous terre, je passerais donc mon tour :-)

  10. #10
    Membre averti Avatar de BakaOnigiri
    Inscrit en
    avril 2002
    Messages
    366
    Détails du profil
    Informations forums :
    Inscription : avril 2002
    Messages : 366
    Points : 425
    Points
    425
    Par défaut
    Citation Envoyé par OuftiBoy Voir le message
    Pour en revenir à ce "nouveau" C++ (ce n'est pas le premier, java était déjà une tentative, mais est encore pire), le temps qu'il soit soit au point, normalisé, popularisé, je serais 6 pieds sous terre, je passerais donc mon tour :-)
    Sauf que Cppfront n'est pas comme Java qui est un langage différent, Cppfront est "convertis" en C++ avant la phase de compilation. Enfin c'est ce que j'ai compris de l'article. Pour moi, Cppfront est au C++ ce que Typescript est au Javascript, une surcouche qui est traduit dans le langage d'origine avant la compilation.

  11. #11
    Responsable Qt & Livres


    Avatar de dourouc05
    Homme Profil pro
    Ingénieur de recherche
    Inscrit en
    août 2008
    Messages
    26 364
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur de recherche
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2008
    Messages : 26 364
    Points : 187 888
    Points
    187 888
    Par défaut
    Citation Envoyé par BakaOnigiri Voir le message
    Bon, et maintenant je me demande comment un décrit un langage de programmation, Typescript et Cppfront qui sont une autre manière de décrire du code et qui deviennent un autre code avant la phase de compilation sont-ils des langages de programmations ? Hum ... bon cela semble évident que oui, mais je fait tout de même une distinction entre ces 2 outils et Carbon, Go, Rust ...
    En fait, la distinction n'est pas au niveau des langages, mais des outils : TypeScript et CppFront ont des transpilateurs (qui transforment en JavaScript ou C++), les autres ont de vrais compilateurs. Rien n'empêche que Clang se mette à lire directement le code en CppFront, sans passer par une transpilation en C++. D'ailleurs, le C++ a commencé comme ça : une transpilation vers le C, avec cfront, avant d'avoir un langage plus complet/complexe et de vrais compilateurs.
    Vous souhaitez participer aux rubriques Qt (tutoriels, FAQ, traductions) ou HPC ? Contactez-moi par MP.

    Créer des applications graphiques en Python avec PyQt5
    Créer des applications avec Qt 5.

    Pas de question d'ordre technique par MP !

  12. #12
    Membre chevronné

    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2015
    Messages
    391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vendée (Pays de la Loire)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : avril 2015
    Messages : 391
    Points : 1 821
    Points
    1 821
    Par défaut
    C'est marrant, en lisant les points mentionnés j'en arrive à me demander pourquoi les gens passent autant de temps et dépensent autant d'énergie pour ré-inventer Pascal. Ca semble une remarque en l'air, mais jetez un oeil, vous risquez une belle surprise.

    Sur le fond, je m'interroge sur le foisonnement de langages à la syntaxe proche. C'est un excellent moyen d'introduire de la confusion où elle est le plus malvenue. Et puis, des trucs tiennent quand même de la croyance : Pourquoi déclarer une fonction par "fn" et non par "function" ? Six caractères de plus, c'est trop aujourd'hui, ça ne tient plus sur la carte perforée ?

    Durant une trentaine d'années j'ai entre autres assuré la maintenance d'applications écrites des générations avant moi, sur d'autres systèmes. Ce qui a permis de faire durer ce code était sa lisibilité relative et la stabilité de la plateforme cible (VMS - COBOL, Pascal, C). Aujourd'hui, j'ai une impression de grande agitation, et de très peu d'efficacité.

    J'ai l'impression que des démarches comme celle décrite dans l'article ne tiennent aucun compte du rapport coût/bénéfice, du gain réel qu'on peut en attendre. Si un langage est sujet à erreurs, qu'il est cryptique, que sa syntaxe est ambiguë, etc etc, il faut se poser les bonnes questions : Pourquoi le conserver, pourquoi à toute force vouloir le faire évoluer sans changer ses fondamentaux ?

    Aujourd'hui, C est un langage fondamental puisqu'il s'agit du dialecte parlé par toutes les plateformes. Mais on pourrait aussi s'arrêter là, un langage bas niveau suffit, et former les gens à l'utiliser correctement, ce qui semble encore loin d'être fait. On pourrait aussi admettre qu'il est plus important de pouvoir se concentrer sur la compréhension d'un domaine et de ses problèmes plutôt que sur les spécificités de la x-ième version du langage choisi pour les résoudre.

    Un bon développeur qui maitrise à fond un langage rustique vaut toujours mille fois mieux qu'un mauvais développeur qui ne maitrise pas le langage le plus sophistiqué du moment.

  13. #13
    Membre actif
    Homme Profil pro
    amateur
    Inscrit en
    juillet 2015
    Messages
    62
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : amateur

    Informations forums :
    Inscription : juillet 2015
    Messages : 62
    Points : 242
    Points
    242
    Par défaut Je crains que plus ce soit moins, et réciproquement
    Le foisonnement de langages très similaires est une pure gabegie. Je ne peux nier que tel ou tel dialecte apporte certains avantages, ou corrige quelque faiblesse, mais la création de clones, forks, et autres variantes n'est que source de confusion. Ou de querelles de sectes.

    Dans le cas de C++, selon mon expérience -limitée- d'amateur, je perçois une situation paradoxale dans l'évolution du langage: d'une part, il est repensé pour intégrer des concepts modernes de programmation, pour le plus grand bien de la productivité et de la sûreté du code (je veux dire contrôles à la compilation, lisibilité etc), d'autre part il cherche à éviter la création d'un langage alternatif, en assurant une compatibilité ascendante.

    Le paradoxe est que cette compatibilité dont les bénéfices sont clairs pour assurer la maintenabilité de programmes initialisés en C++x et mis à jour en C++y, pour la pérennisation de bibliothèques etc, mais induisent en contrepartie d'une part des inhomogénéités dans le style de codage, d'autre part des syntaxes parfois alambiquées pour substituer un nouveau concept à un ancien, lequel reste d'actualité.

    Personnellement je suis demandeur de conseils pour savoir quels (anciens) éléments du C++ je dois abandonner au bénéfice de quels nouveaux [merci de m'aiguiller vers des pages web en ce sens], les styles de programmation qu'il faut privilégier etc. [oui, je sais que les options de compilation peuvent m'aider en ce sens].
    Pour caricaturer: supprimer (dans l'usage) instructions et syntaxes obsolètes pour que le langage soit plus simple à l'écriture et à la lecture est un plus. Créer des variantes de remplacement ou traitées par un préprocesseur Csuper vers C++ induit des complications mentales, dès lors que syntaxe et mots clés se ressemblent, et que le les niveaux d'abstractions sont du même ordre. Donc améliorer par cet artifice les caractéristiques de C++ apporte à mon avis plus d'inconvénients que d'avantages. Notamment, s'il reste nécessaire d'effectuer le débogage tant en Csuper qu'en C++.

    Cela n'exclut pas que des outils ingénierie logicielle de plus haut niveau aient leur utilité.

  14. #14
    Membre habitué
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2019
    Messages
    68
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juin 2019
    Messages : 68
    Points : 164
    Points
    164
    Par défaut
    la dernière fois où j'ai participé à une discussion ici sur la syntaxe du c++, ça c'est plutôt mal passé, les participants ne voyant pas les problèmes de cette "magnifique" syntaxe, je ne suis pas sur que ça ait beaucoup changé entre temps.
    Ben j'en fait parti : elle me va très bien cette syntaxe. Clair, net, concise. A chaque fois que je vois des "évolution", c'est pour la rendre plus verbeuse, lourde, et in-finé ... plus dans l'esprit du C(++ ou pas).
    Je ne ferai pas le meme commentaire sur les stdlib++ qui génère des exécutables d'une incroyable lourdeur ce qui fini par ralentir l'execution (car contrairement ce que dit m$ pour défendre le charabia que génère ses compilos, plus c'est lourds, plus ca stresse les caches des procs et donc plus c'est long).

    C'est marrant, en lisant les points mentionnés j'en arrive à me demander pourquoi les gens passent autant de temps et dépensent autant d'énergie pour ré-inventer Pascal. Ca semble une remarque en l'air, mais jetez un oeil, vous risquez une belle surprise.
    C'est ce qui fait que j'aime le C et pas le Pascal : trop verbeux !
    Alors oui, fn ou function ne change pas grand-chose, mais un
    est tout aussi parlant.

    Aujourd'hui, C est un langage fondamental puisqu'il s'agit du dialecte parlé par toutes les plateformes. Mais on pourrait aussi s'arrêter là, un langage bas niveau suffit, et former les gens à l'utiliser correctement, ce qui semble encore loin d'être fait. On pourrait aussi admettre qu'il est plus important de pouvoir se concentrer sur la compréhension d'un domaine et de ses problèmes plutôt que sur les spécificités de la x-ième version du langage choisi pour les résoudre.
    100% d'accord. Surtout ceux qui sont venus par la suite n'ont juste apporté de la lourdeur et de la complexité (Java) et quand il s'agit de sécurité, c'est souvent pour palier a l'incompétence des développeurs.

  15. #15
    Expert confirmé

    Profil pro
    Inscrit en
    février 2006
    Messages
    2 360
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 2 360
    Points : 4 664
    Points
    4 664
    Par défaut
    Citation Envoyé par destroyedlolo Voir le message
    Ben j'en fait parti : elle me va très bien cette syntaxe. Clair, net, concise. A chaque fois que je vois des "évolution", c'est pour la rendre plus verbeuse, lourde, et in-finé ... plus dans l'esprit du C(++ ou pas).
    bah non justement, la syntaxe du c++ (et certaines parties du c) n'est en aucun cas ni clair ni net ni concise, rien qu'à voir la tête des grammaires ...

    Citation Envoyé par destroyedlolo Voir le message
    Je ne ferai pas le meme commentaire sur les stdlib++ qui génère des exécutables d'une incroyable lourdeur ce qui fini par ralentir l'execution (car contrairement ce que dit m$ pour défendre le charabia que génère ses compilos, plus c'est lourds, plus ca stresse les caches des procs et donc plus c'est long).
    heu, un programme lourd et le stress des caches des procs, ça n'a à peu près rien à voir.

    Citation Envoyé par destroyedlolo Voir le message
    100% d'accord. Surtout ceux qui sont venus par la suite n'ont juste apporté de la lourdeur et de la complexité (Java) et quand il s'agit de sécurité, c'est souvent pour palier a l'incompétence des développeurs.
    c'est quand même magique, prenons un bon exemple de programme bien complexe, genre un noyau de système d'exploitation, écrit plus ou moins en c à l'heure actuelle, avoir un peu de lourdeur et de complexité pour gérer par exemple, la taille des buffers, aurait permis d'éviter une sacré palanquée de bugs ...
    ... et pourtant il ne me semble pas que ces développeurs soient particulièrement incompétents

  16. #16
    Membre habitué
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2019
    Messages
    68
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juin 2019
    Messages : 68
    Points : 164
    Points
    164
    Par défaut
    Citation Envoyé par stardeath Voir le message
    bah non justement, la syntaxe du c++ (et certaines parties du c) n'est en aucun cas ni clair ni net ni concise, rien qu'à voir la tête des grammaires ...
    Exemple ?
    Les 9/10, ce sont les gens qui n'y pannent rien ni aux pointeurs, ni aux indirections ...

    Citation Envoyé par stardeath Voir le message
    heu, un programme lourd et le stress des caches des procs, ça n'a à peu près rien à voir.
    C'est bien connu que les caches des procs sont extensibles a l'infini. Evidemment ...

    Citation Envoyé par stardeath Voir le message
    c'est quand même magique, prenons un bon exemple de programme bien complexe, genre un noyau de système d'exploitation, écrit plus ou moins en c à l'heure actuelle, avoir un peu de lourdeur et de complexité pour gérer par exemple, la taille des buffers, aurait permis d'éviter une sacré palanquée de bugs ...
    C'est ca, c'est pour ca d'ailleurs que les bousins en Java (pour ne prendre que cet exemple) sont exemptes de toute fuite mémoire, c'est bien connu.
    Quant au dépassement de buffers, nul développeur n'est a l'abri : mais il existe des outils et des sécurités pour les détecter, et ce, depuis des décennies.
    Mais sur des codes aussi complexes avec des milliers d'objets qui interagissent entre eux, aucun langage ne peut garantir qu'il n'y aura jamais de dépassement ou de "race condition" : peut-être qu'ils sortiront une erreur plutot que crasher, mais le problème restera là.

    Citation Envoyé par stardeath Voir le message
    ... et pourtant il ne me semble pas que ces développeurs soient particulièrement incompétents
    Du coup, voir la définition de ... "souvent".

  17. #17
    Expert confirmé

    Profil pro
    Inscrit en
    février 2006
    Messages
    2 360
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 2 360
    Points : 4 664
    Points
    4 664
    Par défaut
    Citation Envoyé par destroyedlolo Voir le message
    Exemple ?
    Les 9/10, ce sont les gens qui n'y pannent rien ni aux pointeurs, ni aux indirections ...
    d'une logique confondante avec pour exemple les mots clés contextuels :
    pire, en général, les gens, sur les pointeurs, c'est pas la syntaxe qu'ils ne comprennent pas, c'est le concept même, qui n'a donc rien à avoir avec la syntaxe ...

    Citation Envoyé par destroyedlolo Voir le message
    C'est bien connu que les caches des procs sont extensibles a l'infini. Evidemment ...
    je vois toujours pas le rapport entre un programme lourd et le cache des procs O_o
    ou alors, va vraiment falloir que tu expliques ta logique que la stdlib++ fasse que le programme soit plus lourd (comment ça d'ailleurs plus lourd, en taille d'exe?) et que cette lourdeur ralenti l'exécution (parce que si la lourdeur que tu dénonces est la taille de l'exe, je répète, ça n'a rien à voir avec le cache).

    Citation Envoyé par destroyedlolo Voir le message
    C'est ca, c'est pour ca d'ailleurs que les bousins en Java (pour ne prendre que cet exemple) sont exemptes de toute fuite mémoire, c'est bien connu.
    Quant au dépassement de buffers, nul développeur n'est a l'abri : mais il existe des outils et des sécurités pour les détecter, et ce, depuis des décennies.
    Mais sur des codes aussi complexes avec des milliers d'objets qui interagissent entre eux, aucun langage ne peut garantir qu'il n'y aura jamais de dépassement ou de "race condition" : peut-être qu'ils sortiront une erreur plutot que crasher, mais le problème restera là.
    mais le but n'est jamais de faire disparaître les problèmes, mais de faire en sorte que les cas triviaux soient gérés.
    si c'est ça l'argument pour ne pas améliorer, restez à l'assembleur, je ne vois même pas pourquoi vous faites à minima du c ...
    et c'est cool, tu veux bien qu'il y ait des outils pour détecter les problèmes, mais faire en sorte que le langage en lui même bénéficie de ça, hors de question ... c'est plutôt paradoxal.

    Citation Envoyé par destroyedlolo Voir le message
    Du coup, voir la définition de ... "souvent".
    bah du coup ça ne marche pas, si le souvent signifie en fait tout le temps, autant donc se démerder pour que le programmeur ait un poids en moins quand il développe, c'est la logique même d'un langage de programmation, le langage c y compris.

  18. #18
    Membre habitué
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2019
    Messages
    68
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juin 2019
    Messages : 68
    Points : 164
    Points
    164
    Par défaut
    Citation Envoyé par stardeath Voir le message
    d'une logique confondante avec pour exemple les mots clés contextuels :
    Je ne comprends là : pour montrer que la syntaxe est problématique ... tu sors justement un exemple ou le mot clef permet de clarifier la volonté du programmeur

    Citation Envoyé par stardeath Voir le message
    pire, en général, les gens, sur les pointeurs, c'est pas la syntaxe qu'ils ne comprennent pas, c'est le concept même, qui n'a donc rien à avoir avec la syntaxe ...
    Yoooouuuuhhhhoooouuuuuu, du coup, supprimions les pointeurs. Ca n'a en effet rien à voir avec la syntaxe mais avec le manque de compétence du programmeur.

    Citation Envoyé par stardeath Voir le message
    je vois toujours pas le rapport entre un programme lourd et le cache des procs O_o
    ... (parce que si la lourdeur que tu dénonces est la taille de l'exe, je répète, ça n'a rien à voir avec le cache).
    Tu peux le répéter autant de fois que tu le veux, ca n'en fera pas une vérité.
    C'est si difficile à comprendre que si un code récurrent ne rentre pas dans le cache, ca implique mécaniquement plus de miss et donc une dégradation importante des perfs ?

    Citation Envoyé par stardeath Voir le message
    mais le but n'est jamais de faire disparaître les problèmes, mais de faire en sorte que les cas triviaux soient gérés.
    Ils le sont déjà :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    #include <stdio.h>
     
    int main( void ){
    	double toto;
    	char res[5];
     
    	toto += 3;
    	sprintf(res, "%f", toto);
    }
    Donne :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    tst.c: Dans la fonction «*main*»:
    tst.c:8:23: attention: la directive «*%f*» écrit entre 3 et 317 octets dans une région dont la taille est 5 [-Wformat-overflow=]
        8 |         sprintf(res, "%f", toto);
          |                       ^~
    tst.c:8:22: note: on suppose que la sortie de la directive occupe 8 octets
        8 |         sprintf(res, "%f", toto);
          |                      ^~~~
    tst.c:8:9: note: «*sprintf*» écrit entre 4 et 318 octets dans une destination dont la taille est 5
        8 |         sprintf(res, "%f", toto);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~
    tst.c:7:14: attention: «*toto*» est utilisé sans avoir été initialisé [-Wuninitialized]
        7 |         toto += 3;
          |         ~~~~~^~~~
    ...
    Et y'en a plein d'autres. Pour les trucs plus péchu, a nouveau, il existe déjà des solutions.

    Citation Envoyé par stardeath Voir le message
    si c'est ça l'argument pour ne pas améliorer, restez à l'assembleur, je ne vois même pas pourquoi vous faites à minima du c ...
    Ouai, puis pourquoi l'assembleur ? Après tout, du code Hexa serait suffisant non ?
    Après, si tu n'arrives pas à comprendre l'avantage de faire du C par rapport à de l'assembleur, franchement, on ne peut pas grand-chose pour toi

    Citation Envoyé par stardeath Voir le message
    et c'est cool, tu veux bien qu'il y ait des outils pour détecter les problèmes, mais faire en sorte que le langage en lui même bénéficie de ça, hors de question ... c'est plutôt paradoxal.
    Je n'ai dit que 2 choses :
    1. Que le C me convient très bien, malgré ses défauts, point de vu tout ce qu'il y a de plus personnel. Enfin, visiblement pas tant que ca car toutes les tentatives pour faire le "remplaçant du C" ont échoué. Ce qu'il ne veut pas dire non plus que ce n'est pas la peine d'essayer faire mieux.
    2. MAIS si c'est pour faire une usine a gaz, un truc hyper verbeux et qui en plus bousille complètement les perfs ... ben ca sera un nouveau langage mais certainement pas un remplaçant au C.


    Si coté perf, Rust semble resté dans la ligne, mais dans mon cas perso, je n'ai pas encore regardé si ces "avancées" m'apporte qq chose ou non, sa portabilité sur les différentes plateformes que j'utilise ... car son compilo est parfaitement lourdingue, d'une lenteur et d'une gloutonnerie rédhibitoire. Et le fait qu'il ne soit pas (encore sans doute) possible de faire de la compilation distribuée, n'aide pas !

    Citation Envoyé par stardeath Voir le message
    bah du coup ça ne marche pas, si le souvent signifie en fait tout le temps,
    "Souvent" signifie ... souvent, rien de plus

  19. #19
    Expert confirmé

    Profil pro
    Inscrit en
    février 2006
    Messages
    2 360
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 2 360
    Points : 4 664
    Points
    4 664
    Par défaut
    Citation Envoyé par destroyedlolo Voir le message
    Je ne comprends là : pour montrer que la syntaxe est problématique ... tu sors justement un exemple ou le mot clef permet de clarifier la volonté du programmeur
    et donc pour toi ce mot clé contextuel est à la bonne place? au secours ... pour montrer que la syntaxe est problématique, je prends un exemple de syntaxe qui a un problème, je vois pas trop où est le problème, pire, dans les différentes "révisions" qu'on voit à gauche et à droite, ça fait justement partie des points qui sont relevés cette incohérence de placement.
    et je répète "mot clé contextuel", je t'invite à écrire un parseur pour voir à quel point c'est une plaie ce concept.

    Citation Envoyé par destroyedlolo Voir le message
    Yoooouuuuhhhhoooouuuuuu, du coup, supprimions les pointeurs. Ca n'a en effet rien à voir avec la syntaxe mais avec le manque de compétence du programmeur.
    heu, on parle de syntaxe, pas de fonctionnalités, toi tu viens parler de fonctionnalités, donc youhou à toi, mais hors sujet.
    tu y tiens vraiment à la compétence du programmeur sur un sujet de syntaxe ...

    Citation Envoyé par destroyedlolo Voir le message
    Tu peux le répéter autant de fois que tu le veux, ca n'en fera pas une vérité.
    C'est si difficile à comprendre que si un code récurrent ne rentre pas dans le cache, ca implique mécaniquement plus de miss et donc une dégradation importante des perfs ?
    tu sais que ça ne veut rien dire ce que tu viens de sortir.
    un code récurrent? what? une traduction please ><
    ne rentre pas dans le cache? quoi qui rentre pas dans le cache? les instructions? les datas?
    donc c'est quoi que tu impliques? qu'un exe qui fait 100 Mo sera intrinsèquement plus lent qu'un exe qui fait 128 ko parce que tu ne peux pas charger l'exe de 100 Mo complètement dans le cache? O_o
    les perfs, mais de quelles perfs tu causes en plus, le code "ne va pas plus vite" en fonction de son "poids" mais de l'algo sous-jacent ; combien d'algo sur les tris, les recherches, sur les matrices sont des gouffres en terme de lignes de code, donc d'exécutable plus lourd, et sont des bénédictions en terme de durée d'exec? (c'est pas une question, en général c'est tous, plus l'algo est imbouffable et difficile et long à écrire, plus le temps d'exec sera faible)
    et plus lent sur quoi? le chargement? l'exécution d'une portion du code? y a juste rien qui marche dans ce que tu racontes ...
    et j'attends toujours ton explication sur la stdlib++ ou le bullshit de ms, mais ça va sûrement être épique, vu le reste ...

    Citation Envoyé par destroyedlolo Voir le message
    Ils le sont déjà :
    donc tu prends un exemple simpliste, et grâce à ça, les protections sont là? purée, je ferais bien une remarque sur la maintenance du noyau linux, mais je vais éviter ><
    tu dis que pour le plus péchu, les techniques sont déjà là, et quoi? c'est donc quoi le problème? que c'est pas utilisé?

    Citation Envoyé par destroyedlolo Voir le message
    Ouai, puis pourquoi l'assembleur ? Après tout, du code Hexa serait suffisant non ?
    Après, si tu n'arrives pas à comprendre l'avantage de faire du C par rapport à de l'assembleur, franchement, on ne peut pas grand-chose pour toi
    ha c'est magique, c'est toi qui vient te plaindre que "holala, mettre des trucs dans le langage, ça contredit l'esprit du c"
    le même mec dit ensuite que regarde y a déjà des trucs dans le c, déjà what et maintenant tu tentes de mettre ça sur le dos des autres???

    Citation Envoyé par destroyedlolo Voir le message
    Je n'ai dit que 2 choses :
    1. Que le C me convient très bien, malgré ses défauts, point de vu tout ce qu'il y a de plus personnel. Enfin, visiblement pas tant que ca car toutes les tentatives pour faire le "remplaçant du C" ont échoué. Ce qu'il ne veut pas dire non plus que ce n'est pas la peine d'essayer faire mieux.
    2. MAIS si c'est pour faire une usine a gaz, un truc hyper verbeux et qui en plus bousille complètement les perfs ... ben ca sera un nouveau langage mais certainement pas un remplaçant au C.
    ici ça parle de c++, tu fais du c si ça te chante, ici, on aimerait (en tout cas, j'aimerai, vu que tu me réponds quand j'aborde du c++ avec du c) peut être avoir des réactions de mecs qui font du c++, c'est super cool d'avoir systématiquement des gens qui viennent se plaindre d'un truc qui ne les concernent pas.
    je ne sais pas c'est quoi cette fixette sur les perfs, c'est un saint graal c'est ça? c'est la seule métrique qui existe dans le dév logiciel c'est ça?
    désolé mais non, à la louche et selon mon xp perso 90% du temps je m'en contrefous des perfs, j'ai juste besoin d'un truc qui tourne raisonnablement vite, et qui soit raisonnablement rapide à écrire et à maintenir.
    et quand j'ai besoin de perf, bah je ne fais pas de c, je reste sur le c++, et je m'occupe de mon algo, et vu que ce qui est soit disant extraordinaire en c sur la perf, bah je le fais aussi bien en c++, avec en plus une partie des avantages du langage mais bon.

    Citation Envoyé par destroyedlolo Voir le message
    Si coté perf, Rust semble resté dans la ligne, mais dans mon cas perso, je n'ai pas encore regardé si ces "avancées" m'apporte qq chose ou non, sa portabilité sur les différentes plateformes que j'utilise ... car son compilo est parfaitement lourdingue, d'une lenteur et d'une gloutonnerie rédhibitoire. Et le fait qu'il ne soit pas (encore sans doute) possible de faire de la compilation distribuée, n'aide pas !
    ça, j'appelle ça une excuse d'un mec qui voit qu'il va peut être falloir qu'il se mette à jour car son langage préféré est en train d'être attaqué.
    et c'est marrant, à chaque fois, il y a toujours un mec pour venir parler des 25 plateformes qu'il utilise et du fait qu'il faut que le compilateur tourne sur un grille pain ; il va peut être falloir arrêter de prendre son cas d'utilisation comme le cas standard.

    Citation Envoyé par destroyedlolo Voir le message
    "Souvent" signifie ... souvent, rien de plus
    continue à chercher des excuses ...

  20. #20
    Membre habitué
    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2019
    Messages
    68
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : juin 2019
    Messages : 68
    Points : 164
    Points
    164
    Par défaut
    Citation Envoyé par stardeath Voir le message
    heu, on parle de syntaxe, pas de fonctionnalités, toi tu viens parler de fonctionnalités, donc youhou à toi, mais hors sujet.
    Relis les échanges précédents.

    Citation Envoyé par stardeath Voir le message
    tu y tiens vraiment à la compétence du programmeur sur un sujet de syntaxe ...
    Un "programmeur" qui ne comprend pas ce qu'est un pointeur ne devrait pas faire de C (++ ou pas). Si t'arrives pas à comprendre pourquoi, là non plus, on ne peut rien pour toi.

    Citation Envoyé par stardeath Voir le message
    tu sais que ça ne veut rien dire ce que tu viens de sortir.
    un code récurrent? what? une traduction please ><
    TU ne comprends pas, nuance. Et puis surtout ...

    Citation Envoyé par stardeath Voir le message
    ne rentre pas dans le cache? quoi qui rentre pas dans le cache? les instructions? les datas?
    donc c'est quoi que tu impliques?
    Ouvre un bouquin et essaie de comprendre comment fonctionne un procs, ses caches, les stratégies ... et puis après continue avec les impactes/stratégies sur un OS multitaches sur un multicore ...

    Citation Envoyé par stardeath Voir le message
    qu'un exe qui fait 100 Mo sera intrinsèquement plus lent qu'un exe qui fait 128 ko parce que tu ne peux pas charger l'exe de 100 Mo complètement dans le cache? O_o
    "Récurrent" ...

    Citation Envoyé par stardeath Voir le message
    ... mais de l'algo sous-jacent ... (c'est pas une question, en général c'est tous, plus l'algo est imbouffable et difficile et long à écrire, plus le temps d'exec sera faible)
    Tout a fait vrai ... mais maintenant, je te laisse ouvrir un bouquin sur l'optimisation. En particulier, sur les nombreuses discussions autour de "l'unrolling".

    Citation Envoyé par stardeath Voir le message
    et j'attends toujours ton explication sur la stdlib++ ou le bullshit de ms, mais ça va sûrement être épique, vu le reste ...
    https://cplusplus.com/forum/windows/52960/
    (je sais, c'est vieux ... mais y'a plein de points qui restent d'actualité).

    Citation Envoyé par stardeath Voir le message
    donc tu prends un exemple simpliste, et grâce à ça, les protections sont là?
    Voila voila ... "mais de faire en sorte que les cas triviaux soient gérés."

    Citation Envoyé par stardeath Voir le message
    purée, je ferais bien une remarque sur la maintenance du noyau linux, mais je vais éviter ><
    Vu le niveau du reste, vaut mieux en effet en resté là

    Citation Envoyé par stardeath Voir le message
    peut être avoir des réactions de mecs qui font du c++, c'est super cool d'avoir systématiquement des gens qui viennent se plaindre d'un truc qui ne les concernent pas.
    Moi, tu vois, j'aurai aimé que t'amène ne serait-ce qu'une preuve concrète des inepties que tu sors. Comme quoi, on ne peut pas tout avoir.
    Ensuite, j'ai parlé de C par abus de langage, les 2 sont évidemment concernés.

    Citation Envoyé par stardeath Voir le message
    selon mon xp perso 90% du temps je m'en contrefous des perfs, j'ai juste besoin d'un truc qui tourne raisonnablement vite, et qui soit raisonnablement rapide à écrire et à maintenir.
    Voila voila, tu t'en contre fou.
    Et puis le jour, ou ton "truc" sera intégré a un plus gros systeme, ou aura à traiter plus de donner, ben pas grave, on changera de machine, puis si ca ne suffit pas (parce que même là y'a des limites, même si ca te parait "incroyable"), ben ca ne sera plus ton probleme.
    C'est aussi ma façon de faire pour du jetable, mais pas pour des trucs qui tournent H24 pendant des années.

    (Heu, juste pour info, ca fait bien longtemps que plus personne je choisis entre les C/C++ sur les perfs ).

    Tu n'apporte jamais le moindre argument factuel, juste du troll ... avec beaucoup de lacunes

    Bon allez, ca s'arrete là pour moi.

Discussions similaires

  1. Réponses: 1
    Dernier message: 01/10/2016, 22h02
  2. Réponses: 1
    Dernier message: 20/06/2007, 00h28
  3. Syntaxe valeurs-par-défaut dans sousformulaire
    Par tAKAmAkA dans le forum IHM
    Réponses: 2
    Dernier message: 08/03/2007, 20h20
  4. Proposition de nouvelles FAQ : Vim (Vi) et d'Emacs.
    Par Yoshidu62 dans le forum Evolutions du club
    Réponses: 3
    Dernier message: 03/11/2006, 19h52

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo