Discussion :

[Metal3d]

Je comprends l'engouement pour Rust et il a sa place dans ce type de projet (pour une fois qu'il sera choisi pour de bonnes raisons...)
Sauf qu'il a aussi des travers et il ça apporter son lot de crasses. Du coup on va avoir 3 langages dans le noyau, des soucis de compilation et des comportements de gestion de mémoire parfois compliqués à gérer. Rust c'est une bonne idée mais il ne faut pas le voir comme le messie.

[Fagus]

... le Trésor Public qui est en train de remplacer le COBOL par Python, autre langage qui peut aussi calculer les décimux avec précision via son module "decimal". Et Python est né en 1989 (33 ans à mûrir avant qu'il soit pris en considération pour commencer à remplacer le COBOL...)

Juste pour illustrer les limites d'un type decimal qui ont été évoquées plus haut, je ne peux rien dire en rust ou cobol, par contre je confirme qu'en python les modules standards sont vraiment pratiques pour le calcul. Le problème d'arrondi peut être géré voire totalement évité.
Le module decimal a une précision par défaut de 28 chiffres (précision pouvant être changée de manière arbitraire). Le module fractions permet le calcul exact des fractions.

Code :

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

1
2
3
4
5
6
7
8
9
In [2]: from decimal import *
 
In [3]: from fractions import *
 
In [4]: Decimal(1) / Decimal (3)
Out[4]: Decimal('0.3333333333333333333333333333')
 
In [5]: Fraction(1,3)+ Fraction(2,3)
Out[5]: Fraction(1, 1)

[Uther]

Le problème des arrondis peut bien sur être géré si on sait bien ce que l'on fait, mais certainement pas totalement évité, sauf si on ne va pas plus loin que la division.
Si on a besoin de trigonométrie, de certaines statistiques, voire même certaines formules comptables un peu complexes, ... on va vite se retrouver avec des nombres réels que l'on est obligé d’approximer comme π, e ou √2.

[Pyramidev]

Comme on parle de fractions :

Code Rust :

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

1
2
3
4
5
6
7
8
9
10
11
12
#!/usr/bin/env rust-script
 
// cargo-deps: num-rational="0.4.1"
use num_rational::Rational32;
 
fn main() {
    let one_third = Rational32::new(1, 3);
    let two_thirds = Rational32::new(2, 3);
    let one = one_third + two_thirds;
    let number = one_third * one_third + two_thirds * two_thirds;
    println!("{one_third}, {two_thirds}, {one} and {number}");
}

Résultat :

Code :

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

1/3, 2/3, 1 and 5/9

Le crate num-rational supporte plusieurs types de fraction.
Rational32 stocke une paire d'entiers de 32 bits.
Il existe aussi Rational64 qui stocke une paire d'entiers de 64 bits.
Si on veut une précision arbitrairement grande, on peut aussi utiliser BigRational qui stocke une paire de BigInt.

PS : je me rends compte que mes deux lignes avec extern crate n'étaient pas nécessaires dans mon précédent message.

[kilroyFR]

J'ai essayé Rust pour voir ce qu'il en etait et si ca valait le coup d'investir du temps. J'ai rapidement laissé tomber. Pourquoi se reformer de 0 pour un langage qui fera la meme chose au final.
Je prefere peaufiner mes connaissances sur C++ et les dernieres normes pour me mettre a jour et tirer partie des ameliorations du langage (sans tout jeter les outils et autres que j'ai l'habitude d'utiliser).

Pour moi c'est autant une mauvaise raison que ceux qui se plaignaient de la gestion memoire ou des pointeurs en C. Trop compliqué de liberer la memoire allouée ? Il faut juste etre rigoureux. D'ailleurs ca se retrouve maintenant avec les nouveaux devs qui n'ont connu que C# dans mes equipes. Ils n'ont aucune notion de gestion des ressources; croient que les ressources sont infinies, l'optimisation de code pour eux c'est remplacer des foreach par des for etc. montent en memoire des listes de plusieurs GOs sans que ca ne les interpelle. Et quand ca ne va pas assez vite, ils mettent en cause le reseau, le manque de memoire etc. Bref jamais aucune remise en cause de leur code.
Bref, mauvais diagnostic et mauvaises optimisations a chaque fois car ils ne comprennent pas comment ca fonctionne et ce que fait concretement leur langage préféré.

J'ai repris recemment un bout de code que j'avais ecrit en C++ il y a 20 ans. Voulu le refaire en C# en equivalent (sans pointeur).
Beaucoup de manipulation de listes en memoire. Au final une perf catastrophique (x5) en C#.
Du coup j'ai prefere remettre a niveau le code vers C++20 pour beneficier des simplifications du langage mais en conservant le code ecrit il y a 20 ans qui fonctionnait toujours de maniere aussi performante (meme plus avec les nouveaux processeurs et compilos).
Bref j'ai arrete de vouloir reecrire des choses perennes qui font le boulot juste pour passer vers un langage a la mode dont la duree de vie n'est pas garantie.

[Uther]

J'ai essayé Rust pour voir ce qu'il en etait et si ca valait le coup d'investir du temps. J'ai rapidement laissé tomber. Pourquoi se reformer de 0 pour un langage qui fera la meme chose au final.

Avec ce type de raisonnement on en serait encore a l'assembleur.
Rust ne permet évidemment pas à l'application finale de faire plus qu'une application écrite en C, cependant, il apporte des abstractions évoluées, de bien plus fortes garanties sur la sécurité, un ensemble d'outils intégrés cohérents, ...

Pour moi c'est autant une mauvaise raison que ceux qui se plaignaient de la gestion memoire ou des pointeurs en C. Trop compliqué de liberer la memoire allouée ? Il faut juste etre rigoureux.

Ce qui ne marche pas dans la pratique. Si on a un programme un minimum complexe, même les développeur chevronnés finissent par laisser passer des erreurs mémoire qui passeront inaperçues.

D'ailleurs ça se retrouve maintenant avec les nouveaux devs qui n'ont connu que C# dans mes equipes. Ils n'ont aucune notion de gestion des ressources; croient que les ressources sont infinies, l'optimisation de code pour eux c'est remplacer des foreach par des for etc. montent en memoire des listes de plusieurs GOs sans que ca ne les interpelle. Et quand ca ne va pas assez vite, ils mettent en cause le reseau, le manque de memoire etc. Bref jamais aucune remise en cause de leur code.

Bref, mauvais diagnostic et mauvaises optimisations a chaque fois car ils ne comprennent pas comment ca fonctionne et ce que fait concretement leur langage préféré.

Des mauvais développeurs, il y en a toujours quelque soient les langages, mais pour le coup, c'est plutôt une excellente raison d'utiliser Rust qui est un langage très peu permissif et qui les oblige à apprendre a gérer correctement soi même pas mal de choses qui sont gérées automatiquement par C#/Java avec un impact sur les performances, ou qui seraient ignorées en C/C++ avec au final des problèmes de qualité.

J'ai repris recemment un bout de code que j'avais ecrit en C++ il y a 20 ans. Voulu le refaire en C# en equivalent (sans pointeur).
Beaucoup de manipulation de listes en memoire. Au final une perf catastrophique (x5) en C#.

Oui mais la on parle pas du même type de langage. Si tu passe d'un langage système à un langage managé, bien sur qu'il faut t'attendre a des performances inférieures. Là on parle des remplaçants à C, donc des langages systèmes comme Zig ou Rust qui sont censés avoir des capacités et des performances similaires.

[Kannagi]

Il faut juste etre rigoureux.

Fallait dire ça aux programmeur de Ariane 5: https://fr.wikipedia.org/wiki/Vol_501_d%27Ariane_5

Le gros désavantage du C , c'est son nombre d'UB et de manque de sécurité.
Et plus le programme est complexe, plus il est difficile de penser à toutes les "possibilité" pour éviter un bug.

[Uther]

Je suis d'accord sur le constat, même si pour le coup, l'exemple n'est pas bon : le code de pilotage qui a posé problème à Ariane 5 était programmé en Ada.

[Sve@r]

Il faut juste etre rigoureux.

Fallait dire ça aux programmeur de Ariane 5: https://fr.wikipedia.org/wiki/Vol_501_d%27Ariane_5

Dans le rapport après accident, il est dit que les essais du système de navigation, qui provenait de Ariane4, n'ont pas été faits pour économiser 800000FF? Ca me semble pas être la faute des programmeurs (qui, eux, avaient codé ce système pour Ariane4 avec toute la rigueur nécessaire à ce lanceur) mais plutôt d'un chef de service quelconque qui a dit "ouais ça mache en v4 ça marchera en v5". Les programmeurs, eux, ne peuvent pas être accusés de manque de rigueur.

Le gros désavantage du C , c'est son nombre d'UB et de manque de sécurité.

Oui, c'est comme ça qu'il se présente. Il dit clairement tout ce qu'on a le droit de faire en disant tout aussi clairement que ce qui n'est pas autorisé n'est alors pas garanti. On peut aimer ou ne pas aimer cet état d'esprit mais on ne peut pas venir le lui reprocher alors qu'on est au courant dès le départ. On n'est pas non plus obligé de faire du C si on juge ce langage inadapté au but à atteindre.

[stardeath]

il y a un paquet d'interventions dans ce thread de personne qui semble ne jamais avoir touché une ligne de c ... bref ...

Oui, c'est comme ça qu'il se présente. Il dit clairement tout ce qu'on a le droit de faire en disant tout aussi clairement que ce qui n'est pas autorisé n'est alors pas garanti. On peut aimer ou ne pas aimer cet état d'esprit mais on ne peut pas venir le lui reprocher alors qu'on est au courant dès le départ. On n'est pas non plus obligé de faire du C si on juge ce langage inadapté au but à atteindre.

un UB n'a rien à voir avec une autorisation, c'est un comportement non défini dans la spec O_o
le problème est donc dans l'identification des UB dans le code que tu as produit vu qu'en général le compilateur ne te dit justement pas où sont les UB possibles dans ton code ...

[Sve@r]

un UB n'a rien à voir avec une autorisation, c'est un comportement non défini dans la spec O_o

Ah c'est bon, arrête de jouer sur les mots. J'ai dit "autorisation" pour simplifier. Un comportement non défini parce que instruction (exemple taper dans tab[-1]) non autorisée.

le problème est donc dans l'identification des UB dans le code que tu as produit vu qu'en général le compilateur ne te dit justement pas où sont les UB possibles dans ton code ...

Ben oui. Ta fonction reçoit l'adresse d'un tableau dans un pointeur, puis elle décale ce pointeur de 50 sans savoir que le tableau d'origine en fait seulement 10 (sans parler du fait que l'appelant peut très bien avoir passé non pas le début du tableau à la fonction mais passé une adresse se situant au milieu du tableau) et va taper à cet endroit. Effectivement le compilateur aura du mal à voir ça. Et donc? Qu'est-ce que cela est censé prouver?? Que le compilateur doit remplacer ton cerveau???

[stardeath]

Ah c'est bon, arrête de jouer sur les mots. J'ai dit "autorisation" pour simplifier. Un comportement non défini parce que instruction (exemple taper dans tab[-1]) non autorisée.

lol, tu confirmes que justement tu ne dois pas faire souvent du c, une fois de plus, même pour simplifier, ça n'a RIEN à voir avec une autorisation, le code que tu écris peut potentiellement être totalement valide, exemple si ton compilateur complète la spec en définissant les comportement des UB ...
pire, l'exemple que tu prends peut être parfaitement défini ...

Ben oui. Ta fonction reçoit l'adresse d'un tableau dans un pointeur, puis elle décale ce pointeur de 50 sans savoir que le tableau d'origine en fait seulement 10 et va taper à cet endroit. Effectivement le compilateur aura du mal à voir ça. Et donc? Qu'est-ce que cela est censé prouver?? Que le compilateur doit remplacer ton cerveau???

tu as déjà développé qqch? parce que l'homme, justement pour compléter ce que la spec et les compilateurs ne font pas, a créé des outils genre analyse statique et autres qui justement eux sont capables de détecter un paquet d'erreurs possibles ...
mais visiblement ton cerveau génial ne fait jamais d'erreur, ou ne code pas, au choix.

bref ...

[Bktero]

C'est bien de faire des leçons sur les gens qui ne feraient pas de C, mais il faut éviter de dire des bêtises ensuite

ton compilateur complète la spec en définissant les comportement des UB

Non.

Il définit les comportements des "implementation-defined behaviors". Les "undefined behaviors" ne sont jamais définis.

Voir https://stackoverflow.com/a/2397995/12342718

[stardeath]

non mais sérieux, tu lis ce que tu as écrit au moins?

Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

"documented manner characteristic of the environment" ça s'appelle définir le comportement ... mais au secours ...

[Sve@r]

lol, tu confirmes que justement tu ne dois pas faire souvent du c

Ouais, pas souvent. Tu as fait une recherche sur mon pseudo dans le fofo C pour voir ce que j'y avais écrit ou bien tu veux juste provoquer gratuitement ?

non mais sérieux, tu lis ce que tu as écrit au moins?

En tout cas on lit au moins ce que tu écris et ce qui en sort, en dehors des provocations gratuites... rien.

[stardeath]

la première chose que je fais quand on me montre que je me suis planté sur un point technique c'est d'admettre que je me suis planté.
ici, le sport national c'est de trouver tous les moyens nécessaires pour ne pas perdre la face, quitte à se justifier avec un écrit qui au final ne contredit rien.

mais t'as raison, si tu ne tires rien de ce que j'ai écrit, je vais arrêter de lire/écrire sur ce sujet, j'ai autre chose à faire de mes journées

[Uther]

Oui, c'est comme ça qu'il se présente. Il dit clairement tout ce qu'on a le droit de faire en disant tout aussi clairement que ce qui n'est pas autorisé n'est alors pas garanti. On peut aimer ou ne pas aimer cet état d'esprit mais on ne peut pas venir le lui reprocher alors qu'on est au courant dès le départ. On n'est pas non plus obligé de faire du C si on juge ce langage inadapté au but à atteindre.

Sauf que ça c'est de la théorie, mais ça ne tient pas l'épreuve de la pratique. Ce qui te dit ce que tu as le droit de faire ou non en C, ce n'est pas le langage mais sa spécification, que probablement moins de 1% des dev C ont lu. Je serais surpris que beaucoup de développeur C connaisse seulement la moité des presque 200 cas de comportement indéfinis dans le langage. Et même les cas que l'on connait, c'est pas toujours évident de les éviter. Dans un code un minimum complexe, même les meilleurs programmeur en laisseront passer.
Pour le coup un langage qui te dis bien ce que tu as et n'as pas le droit de faire c'est Rust. Il te met dans des clous qui font que tu ne peux pas rencontrer de comportement indéfini a moins que tu décides volontairement de prendre le risque en le signalant explicitement via un bloc 'unsafe'.

On peut tout a fait utiliser un langage pour certaines raison et trouver qu'il pose problème pour d'autres. Et non on a pas toujours le choix. Il y a encore beaucoup de cas ou il est difficile de faire autre chose que du C ou du C++, c'est pour ça que les alternative récentes comme Rust ou Zig changent la donne en offrant de vraies nouveautés au développeurs bas niveau.

[Sve@r]

la première chose que je fais quand on me montre que je me suis planté sur un point technique c'est d'admettre que je me suis planté.

Alors déjà ici on ne parlait pas de technique mais de généralités sur le C. Et surtout tu n'as absolument rien montré à personne (enfin rien d'autre que ton infinie suffisance), tu t'es juste contenté de pinailler sur les termes et provoquer sans rien apporter de concret au débat.

mais t'as raison, si tu ne tires rien de ce que j'ai écrit

Malheureusement je crois qu'il n'y a pas que moi qui ne tire rien de ce que tu as écrit. En fait, le seul à tirer quelque chose de ce que tu as écrit c'est toi.

, je vais arrêter de lire/écrire sur ce sujet, j'ai autre chose à faire de mes journées

Oui oui, c'est ça, fais bien le type qui s'en va comme un prince mais qui en fait s'en va juste pitoyablement parce qu'il n'avait en réalité rien d'intéressant à dire.

Et non on a pas toujours le choix.

Ok, une fois on m'a imposé C là ou Python aurait été bien plus adapté (un programme qui selon les ordres qu'on lui passait en option, modifiait des valeurs dans un fichier). Mais c'est parce que le programme devait tourner sur une caméra avec un OS mini-linux et qu'il n'y avait pas Python dessus. Mais ça ne m'est arrivé qu'une seule fois et j'espère que c'est aussi une rareté chez les autres (en plus le demandeur était super sympa, quand je lui ai dit que je voyais mieux Python pour son truc il m'a expliqué le souci mais m'a demandé quand-même si je voulais qu'il essaye de compiler Python pour me simplifier le codage...)

c'est pour ça que les alternative récentes comme Rust ou Zig changent la donne en offrant de vraies nouveautés au développeurs bas niveau.

A te lire (et aussi en survolant les tutos) ça donne envie et j'aimerais bien avoir le temps de regarder Rust (quand je me suis mis à Python c'était suite à un conseil analogue reçu sur un autre forum). En plus je viens de voir qu'il intègre Qt. Mais malheureusement je n'ai pas le temps (et j'en suis le premier désolé).

[Uther]

Mais ça ne m'est arrivé qu'une seule fois et j'espère que c'est aussi une rareté chez les autres.

Quand je dis qu'on n'a pas le choix ça peut être soit pour des raison humaines (choix des responsables techniques, ...) ou par des contraintes technique comme dans ton cas. Il y a peu pour faire du bas niveau un minimum performant, il n'y avait pas trop le choix, c'était soit C ou C++, éventuellement Ada (mais c'était compliqué).
Avec l'arrivée des langage bas niveau modernes on a enfin un peu plus de choix quand on vise le bas niveau.

A te lire (et aussi en survolant les tutos) ça donne envie et j'aimerais bien avoir le temps de regarder Rust (quand je me suis mis à Python c'était suite à un conseil analogue reçu sur un autre forum). En plus je viens de voir qu'il intègre Qt. Mais malheureusement je n'ai pas le temps (et j'en suis le premier désolé).

Attention Rust n’intègre pas Qt de manière très naturelle. De manière générale les interfaces graphique sont vraiment le point sur lequel Rust ne propose pas encore de solution vraiment satisfaisante. Il y a beaucoup de projets très variés mais aucun n'est vraiment mature.

[Bktero]

non mais sérieux, tu lis ce que tu as écrit au moins?

Ton agressivité n'a pas sa place ici, que ce soit à mon endroit ou envers les autres personnes qui participent à cette discussion. Merci.

(en fait, on pourrait juste dire que l'agressivité n'a pas sa place ici)

"documented manner characteristic of the environment" ça s'appelle définir le comportement ... mais au secours ...

Ca s'appelle effectivement définir un comportement, mais tu tronques totalement la citation et en détourne le sens. Face à un "undefined behavior", le compilateur peut plusieurs choses. Une de ces choses est de définir un comportement et de s'y tenir. Mais ça reste une possibilité, et ce n'est pas obligatoire, comme le dit la citation complète.

Je conseille à tout le monde de lire cet article "What Every C Programmer Should Know About Undefined Behavior" http://blog.llvm.org/2011/05/what-ev...ould-know.html Ca montre vraiment à quel point les UB sont dangereux et imprédictibles.