Discussion :

[Patrick Ruiz]

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.

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.

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.

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

[SimonKenoby]

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.

[onilink_]

@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).

[BakaOnigiri]

C'est marrant, pour un article qui doit nous présenter Cppfront, 50% présente Carbon

[Pierre Louis Chevalier]

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

[stardeath]

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".

[BakaOnigiri]

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 ...

[Pierre Louis Chevalier]

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.

[OuftiBoy]

...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 :-)

[BakaOnigiri]

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.

[dourouc05]

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.

[TJ1985]

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.

[Axel Mattauch]

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 C_super 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 C_super qu'en C++.

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

[destroyedlolo]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void trucmuch(int);

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.

[stardeath]

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 ...

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.

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

[destroyedlolo]

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 ...

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 ...

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à.

... et pourtant il ne me semble pas que ces développeurs soient particulièrement incompétents

Du coup, voir la définition de ... "souvent".

[stardeath]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void foo() override;

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 ...

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).

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.

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.

[destroyedlolo]

d'une logique confondante avec pour exemple les mots clés contextuels :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void foo() override;

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

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.

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 ?

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.

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

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 !

bah du coup ça ne marche pas, si le souvent signifie en fait tout le temps,

"Souvent" signifie ... souvent, rien de plus

[stardeath]

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.

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 ...

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 ...

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é?

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???

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.

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.

"Souvent" signifie ... souvent, rien de plus

continue à chercher des excuses ...

[destroyedlolo]

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.

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.

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 ...

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 ...

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" ...

... 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".

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é).

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."

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à

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.

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.