Discussion :

[moldavi]

Il est possible de programmer en pseudo "languages-trucs" beaucoup de choses; cela ne justifie pas pour autant d'affirmer que l'ajout d'une couche d'abstraction "object" améliore l’efficacité ou la compréhension intime de ce qu'il se passe au niveau du matériel.

Pour de la compréhension intime, alors ce sera de l'assembleur. Le C et le C++ cachent les mêmes choses, qui font que ce n'est pas du tout intime au niveau matériel. Enfin bref c'est pas parce que je manipule 2 pointeurs en C/C++, que je me sens intime avec le matériel. Avec l'assembleur, là oui, ça commence à être intime.

Pour le pseudo C++, ça veut juste souvent dire, pas d'héritage, pas de template, etc. Mais par contre, il y a toujours le truc super efficace, l'encapsulation. D'ailleurs, le javascript, le php, le python, ont introduit des doses de pseudo C++. On se demande pourquoi.

En fait, l'encapsulation, c'est le truc universel où tous les développeurs devraient être d'accord sur les avantages que cela apporte.

[air-dex]

Rust a un compilateur, un débogueur, un générateur de doc, etc... ça alors mais quel exploit ! C'est vraiment le seul langage du monde à faire ça...
Et du coup c'est quoi la commande cargo pour intégrer et réutiliser une lib C ou fortran ?

Bien sûr que ce n'est pas le seul. Mais il n'empêche que le côté "prêt à coder" est un avantage sur d'autres technos. gdb et Doxygen ne sont pas automatiquement installés quand tu "installes" C et C++.

[Bill Fassinou]

Les derniers correctifs du projet Rust for Linux montrent que le langage Rust avance à grands pas vers le noyau
Torvalds estime que cela pourrait être prêt pour la version 5.14

Linux 5.13 a été publié fin juin sans le support du langage Rust, mais Linus Torvalds a déclaré en avril que le projet Rust for Linux a maintenant beaucoup avancé et pourrait être fusionné avec la prochaine mouture du noyau, Linux 5.14. Miguel Ojeda, chef du projet Rust for Linux, a soumis un nouvel ensemble de correctifs à la liste de diffusion de Linux qui résume les progrès du projet visant à permettre l'utilisation de Rust aux côtés de C pour l'implémentation du noyau. Les progrès sont significatifs, allant de l'utilisation d'un compilateur Rust bêta, le test du support des architectures ARM et RISC-V, de nouvelles abstractions Rust, etc.

Miguel Ojeda est un informaticien du CERN à Genève, en Suisse, qui travaille maintenant à plein temps sur le projet Rust for Linux. Dans son billet, il a commencé par expliquer que les allocations infaillibles ont été supprimées par le biais d'un crate de bibliothèque standard "alloc" personnalisé. En effet, une allocation infaillible, c'est lorsqu'un développeur suppose qu'une allocation de mémoire va toujours réussir. Si elle ne réussit pas, Rust met fin au processus. Les allocations infaillibles ne sont pas acceptables dans le noyau, car les échecs provoquent une panique du noyau. Une allocation faillible permet au développeur de tester le succès.

Ojeda a écrit que les intrinsèques de panique de "compiler_builtins" sont toujours là, mais ils seront résolus en partitionnant "core" via des portes de fonctionnalités. La première, pour désactiver la fonctionnalité de virgule flottante, vient d'être acceptée en amont. « À terme, l'objectif est d'avoir tout ce dont le noyau a besoin dans "alloc" en amont et de le supprimer de l'arbre du noyau », a-t-il déclaré. Plusieurs autres améliorations majeures ont été apportées au support général de Rust. Les sous-sections suivantes les couvrent.

Support d'un compilateur Rust bêta

Rust for Linux nécessite de nouvelles fonctionnalités dans le compilateur Rust (rustc) ainsi que dans le code du noyau. Mais jusqu'à présent, le projet n'a utilisé que les versions nightly de rustc, car il a besoin des derniers correctifs et des fonctionnalités instables. Cela n'est plus désormais nécessaire, car le noyau peut maintenant être compilé avec les versions bêta et stable de rustc. Pour le moment, le projet utilise la version 1.54-beta1 comme compilateur de référence. À la fin de ce mois, la version 1.54 de rustc sera publiée, et le projet passera à cette version comme référence.

Notez que le noyau nécessite toujours des fonctionnalités instables, même s'il est compilé avec une version stable de rustc. Ainsi, Ojeda a déclaré que l'équipe ne pourra pas garantir que les futures versions de rustc fonctionneront sans changements dans l'arbre du noyau. « De ce fait, jusqu'à ce que toutes les fonctionnalités instables dont nous avons besoin soient stabilisées, nous supporterons une seule version de rustc pour chaque version du noyau », a-t-il déclaré. L'écriture de tests unitaires pour le code du noyau Rust fonctionne maintenant avec l'attribut standard Rust #test.

Ils ne s'exécutent pas encore dans le noyau, mais selon Ojeda, « l'objectif est de les faire fonctionner dans l'espace du noyau, afin que nous puissions tester le code qui dépend des fonctionnalités du noyau ».

Architectures et support du compilateur

« Nous avons demandé à Compiler Explorer d'ajouter le support de tous les compilateurs alternatifs. Au moment d'écrire ces lignes, ils ont déjà ajouté mrustc et GCC Rust ; et rustc_codegen_gcc sera bientôt disponible », a-t-il déclaré. Autrement dit, les architectures ARM et RISC-V sont maintenant supportées, grâce au travail sur rustc_codgen_gcc, qui est un codegen GCC pour rustc. Cela signifie que rustc effectue la compilation initiale du code Rust, mais que GCC (la collection de compilateurs GNU) effectue la compilation finale, ce qui permet la prise en charge des architectures que GCC supporte.

Il existe une proposition pour fusionner ce travail dans la base de code principale de Rust, ce qui soulève un problème de licence, car Rust utilise les licences MIT et Apache v2 alors que GCC utilise la GPLv3. La Fondation Rust a examiné la question et a conclu que : « le changement proposé n'aura pas d'impact sur la licence de rustc sauf lorsqu'il est construit avec le back-end gcc, auquel cas la GPLv3 s'appliquera au binaire résultant » – ce qui signifie le binaire du compilateur, pas les applications qu'il compile.

Abstractions Rust et mises à jour des pilotes

Ojeda a annoncé que l'équipe de Rust for Linux a développé de nouvelles abstractions Rust qui utilisent les implémentations du noyau C, notamment : red-black trees, reference-counted objects, file descriptor creation, tasks, files, io vectors, etc. En outre, l'équipe a aussi amélioré le support des pilotes : améliorations de "file_operations" (plus d'opérations supportées, état arbitraire), de la macro module!, des macros d'enregistrement, des pilotes de plateforme rudimentaires ("probe" et "remove"), la réduction du code passe-partout, etc.

Selon le message d'Ojeda, sur Binder, il y a maintenant un support pour le transfert des descripteurs de fichiers et des hooks LSM ; et l'équipe travaille sur des chiffres préliminaires de performance. De plus, un travail est en cours sur un pilote d'exemple Rust, bcm2835-rng. Il s'agit du générateur de nombres aléatoires matériel présent sur les Raspberry Pi Zero(W), Classic, Two et Three. Il y a d'autres petites améliorations, comme le fait que les pilotes sont limités sur les fonctionnalités instables qu'ils peuvent utiliser.

Quel est le statut des séries de correctifs ?

Selon Ojeda, la prise en charge de Rust est toujours considérée comme expérimentale. Cependant, comme indiqué en avril, le support est suffisamment bon pour que les développeurs du noyau puissent commencer à travailler sur les abstractions Rust pour les sous-systèmes et écrire des pilotes et autres modules. Il faut noter que les séries actuelles de correctifs viennent "linux-next", donc la première exécution a eu lieu mardi dernier.

Soutien de la communauté à Rust for Linux

Le projet bénéficie d'un soutien important de la part de l'industrie. En avril, Google a déclaré : « Nous pensons que Rust est désormais prêt à rejoindre le langage C en tant que langage pratique pour l'implémentation du noyau et que cela réduirait le nombre de bogues et de failles de sécurité potentiels ». Google sponsorise Ojeda pour qu'il travaille à temps plein sur le projet pendant un an, par l'intermédiaire de l'ISRG (Internet Security Research Group). L'ISRG a déclaré le mois dernier que cela s'inscrivait dans le cadre des efforts visant à faire évoluer l'infrastructure logicielle critique d'Internet vers un code sûr pour la mémoire.

L'ISRG est également l'organisation à but non lucratif à l'origine des certificats de sécurité gratuits Let's Encrypt. Ojeda a mentionné que le groupe Linux Systems de Microsoft contribue et espère soumettre certains pilotes Hyper-V écrits en Rust. Arm promet une assistance avec Rust pour Linux sur les systèmes basés sur ARM. IBM a contribué au support du noyau Rust pour son processeur PowerPC. Plus de détails devraient être révélés lors de la prochaine conférence Linux Plumbers en septembre. En attendant, le projet est disponible sur GitHub.

Linus Torvalds a déclaré à plusieurs reprises qu'il se réjouissait de la possibilité d'utiliser Rust aux côtés de C pour le développement du noyau, et a déclaré à en avril que le projet a atteint un point où il pourrait être fusionné avec la version 5.14 du noyau.

Sources : Miguel Ojeda, Rust for Linux

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi

Linux 5.13 est disponible avec le support de l'Apple M1, Landlock, FreeSync HDMI et a été publié sous le nom de code "Opossums on Parade"

La prise en charge de Rust pour le développement du noyau Linux commence à prendre forme, le langage fait un premier pas vers la branche "Linux-Next"

La prise en charge de Rust pour le développement du noyau Linux fait l'objet d'une nouvelle série de discussions, après une proposition de RFC

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

[coder_changer_vie]

"Google sponsorise Ojeda pour qu'il travaille à temps plein sur le projet pendant un an"

Suis-je le seul à penser que venant d'un grand groupe, ce type d'investissement semble démesurément ridicule aux regard des enjeux / bénéfices techniques ?

C'est pas comme si le noyau était largement utilisé par Google pour Android (à vérifier mais je dois pas être loin si c'est un fork).

j'ai pas suivi en détail, mais c'est le reflexe pavlovien que ça inspire en première lecture

[AoCannaille]

C'est pas comme si le noyau était largement utilisé par Google pour Android (à vérifier mais je dois pas être loin si c'est un fork).

Sans compter les ~900 000 serveurs de googles qui génèrent genre 90% de leur chiffre d'affaire...

[Bruno]

Plusieurs améliorations ont été apportées au support de Rust dans le noyau Linux,
personnalisation de core et alloc, abstractions et mises à jour des pilotes

Linux 5.13 a été publié fin juin sans le support du langage Rust, mais Linus Torvalds avait déclaré en avril que le projet Rust for Linux a maintenant beaucoup avancé et pourrait être fusionné avec la prochaine mouture du noyau, Linux 5.14. Dans une lettre publiée le 6 décembre, Miguel Ojeda, chef du projet Rust pour Linux, présente explique les principaux changements et mises à jour effectués depuis la version 1 du noyau linux. « Il s'agit de la série de patchs (v2) pour ajouter le support de Rust comme second langage au noyau Linux », a déclaré Miguel dans la liste de diffusion publié le 6 décembre.

Les développeurs de Linux discutent depuis un moment de la perspective de permettre l'utilisation du langage développé par Mozilla Research pour écrire de nouveaux pilotes de périphériques pour le noyau. L'année dernière, les développeurs du noyau Linux semblent s'être mis d'accord sur le sujet. Pour mémoire, Rust est plébiscité, car il offre plusieurs avantages, notamment en ce qui concerne la mémoire. Les partisans de Rust ont cité des travaux qui montrent qu'environ deux tiers des vulnérabilités du noyau auxquelles ont été attribués des CVE sur Android et Ubuntu sont tous liés à des problèmes de sécurité de la mémoire.

Dans un post publié sur son blog le 14 avril, l’équipe de développement de Google a annoncé qu’elle participe à l'évaluation du langage Rust pour le développement du noyau Linux. Suite à cette déclaration, Linus Torvalds, ingénieur logiciel, créateur principal et développeur du noyau Linux, a déclaré lors d’une interview que des discussions sur le sujet seraient beaucoup plus importantes qu'un long post de Google sur le langage. Interrogé sur la suggestion d'un internaute qui a indiqué que, « la solution ici est simple : il suffit d'utiliser C++ au lieu de Rust », Linus Torvalds n'a pas pu se retenir et aurait même traité le C++ de « langage de m... ».

Rappelons qu’au mois de mars, le tout premier support permettant l'utilisation du langage de programmation Rust dans le noyau Linux est apparu dans l'arbre Linux-Next pour des tests plus étendus avant son inclusion éventuelle dans le noyau principal. Juste derrière, une "demande de commentaires" a été relancée sur la liste de diffusion du noyau autour des perspectives du code Rust pour le noyau Linux. Miguel Ojeda, développeur du noyau Linux, a lancé une proposition de RFC (Request For Comments) sur la liste de diffusion du noyau Linux.

Miguel Ojeda, a lancé une proposition de RFC sur la liste de diffusion du noyau Linux. Le message de la liste de diffusion décrivait les convictions des développeurs impliqués dans l'ajout du code Rust au noyau, les avantages tels que l'amélioration de la sécurité de la mémoire, et plus encore. « Certains d'entre vous ont remarqué ces dernières semaines et ces derniers mois qu'une tentative sérieuse d'apporter un second langage au noyau était en train de se forger. Nous y sommes enfin, avec une RFC qui ajoute le support pour Rust au noyau Linux », avait déclaré Miguel Ojeja. « Nous savons qu'il y a des coûts et des risques énormes à introduire un nouveau langage dans le noyau », avait-il ajouté. Voici, ci-dessous, les améliorations qui ont été apportées au support général de Rust :

Stabilité du compilateur

L’équipe du projet Rust pour Linux est passée du compilateur Rust beta à l'utilisation des versions stables, en migrant à chaque fois qu'une nouvelle version est publiée. En mettant à jour le compilateur, L’équipe a été en mesure de retirer de la liste quelques fonctionnalités instables : const_fn_transmute, const_panic, const_unreachable_unchecked, core_panic et try_reserve.

Personnalisation de `core` et `alloc`

Quelques options de modularisation supplémentaires ont été ajouté à alloc afin de désactiver certaines fonctionnalités inutiles : no_rc et no_sync. « Nous aimerions remercier Rust pour avoir travaillé avec nous sur ces options afin que le noyau puisse les utiliser », a déclaré Miguel. En amont, afin que le cas d'utilisation du noyau soit bien pris en charge, ou, plus précisément, la "combinaison" d'options dont le noyau a besoin, Upstream core a aussi ajouté no_fp_fmt_parse.

Rust a activé un certain nombre de diagnostics supplémentaires pour le compilateur Rust et de Clippy
lints. Une différence par rapport à C est que les diagnostics Rust sont un peu plus faciles à désactiver dans le code ce qui apporte plus de rigueur dans le cas général.
Abstractions et mises à jour des pilotes L’équipe a ajouté des abstractions pour les verrous de séquence, les callbacks de gestion d'énergie, la mémoire io (readX/writeX), les puces irq et les gestionnaires de flux de haut niveau, les puces gpio (y compris les puces irq), les périphériques, les périphériques amba et les pilotes.

Le support des pilotes est amélioré avec une infrastructure indépendante du bus, des objets révocables, des mutex révocables, des itérateurs de bits efficaces, de meilleurs diagnostics de panique et des wrappers de pointeurs simplifiés. De plus, elle a amélioré et simplifié les objets Ref (soutenus par refcount_t) et remplacé toutes les instances de Rust. Un nouveau pilote pour les périphériques gpio PL061 a été implémenté et est soumis en tant que patch RFC.

Le support de Rust est toujours considéré comme expérimental. Cependant, le support est assez bon pour que les développeurs de noyaux commencent à travailler sur les abstractions Rust pour les sous-systèmes et à écrire des pilotes et autres modules. La série actuelle vient d'arriver dans Linux-next, donc la première exécution aura lieu cette semaine.

Source : Liste de diffusion

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

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

Les derniers correctifs du projet Rust for Linux montrent que le langage Rust avance à grands pas vers le noyau, Torvalds estime que cela pourrait être prêt pour la version 5.14

La prise en charge de Rust pour le développement du noyau Linux commence à prendre forme, le langage fait un premier pas vers la branche "Linux-Next"

L'année 2020 est-elle celle de Rust au sein du noyau Linux ? C'est ce que suggère une sortie de Linus Torvalds, qui donne des instructions sur l'introduction de son support au système de build

[bmoraut]

Le C++ est décrié par tous ceux qui ont du mal avec la POO.

C'est le Langage le plus rapide et puissant.

Il est aussi sécurisé si on le connait bien:
- Assertions
- Mode de "Débuggage"

Mais comme il est décrié par les universitaires, qui ne veulent pas se casser la tête à écrire des cours,
les ingé ont du mal à s'y mettre.

Abandonné le C++ par Microsoft serait une grave erreur,
qui conduirait à une perte de savoir et de codes sources de valeurs.

[Uther]

C'est le Langage le plus rapide et puissant.

C'est un langage rapide et puissant mais certainement pas le plus rapide et puissant. Le C et le Rust on des performance similaires.

Il est aussi sécurisé si on le connait bien:
- Assertions
- Mode de "Débuggage"

Visiblement tu ne le maitrises pas toi même, car ce n'est clairement pas le mode de débogage et les assertions qui sont les points important pour assurer la sécurité en C++.

Mais comme il est décrié par les universitaires, qui ne veulent pas se casser la tête à écrire des cours,
les ingé ont du mal à s'y mettre.

C'est pas le rôle des universitaire d'apprendre tous les détail d'un langage de programmation. Il sont là pourra apprendre les concepts généraux. Et comme C++ est bourré de complexité qui lui sont assez particulière, c'est normal que les universités avec un temps de cours limité ne puissent pas tout couvrir. Si tu veux un bon niveau de formation au C++, et même dans n'importe quel langage, il faut aller bien au delà de ce qu'on apprend à l''université.

Abandonné le C++ par Microsoft serait une grave erreur,
qui conduirait à une perte de savoir et de codes sources de valeurs.

Il faut sortir du fantasme du grand remplacement. Personne n'envisage de jeter à la poubelle du code parfaitement fonctionnel pour le remplacer par une récriture de qualité moindre. Pour réécrire un code,il faut que ça apporte un réel gain.

[Kannagi]

Abandonné le C++ par Microsoft serait une grave erreur,
qui conduirait à une perte de savoir et de codes sources de valeurs.

Tu sais que le C++ sert à autre chose que de faire un OS Windows ?
une grande partie (en tout cas à ma connaissance) sert pour le jeux video , mais aussi dans l'embarqué , arduino utilise le C++ comme langage par défaut (que bizarrement beaucoup croye que c'est du C... )

[bmoraut]

"Visiblement tu ne le maitrises pas toi même, car ce n'est clairement pas le mode de débogage et les assertions qui sont les points important pour assurer la sécurité en C++."

Qu'est ce que tu en sais que je ne maitrise pas le C++ ?

Surtout en disant les modes de débuguage et les assertions ne sont pas le points importants pour assurer la sécurité du code !

Merci de rester poli et de ne pas faire des affirmations sans savoir.

On ne peut pas entamer une discutions saine et constructive avec des gens comme toi !

[bmoraut]

"C'est pas le rôle des universitaire d'apprendre tous les détail d'un langage de programmation. Il sont là pourra apprendre les concepts généraux. Et comme C++ est bourré de complexité qui lui sont assez particulière,..."


Le C++ n'est pas bourré de complexité mais de fonctionnalité, quand on les comprends, qui sont géniales.

Je les utilisent et c'est un énorme avantage par rapport à d'autre langage, en terme de structures comme en terme d'efficacités.

"c'est normal que les universités avec un temps de cours limité ne puissent pas tout couvrir. ..."

Je suis d'accord, et d'ailleurs il me semble que dans certains pays les master en Info ont une année de plus pour justement les couvrir.
J'en ai parlé avec mes profs car ils se posaient la question de justement mettre ce gendre d'UV.

"Si tu veux un bon niveau de formation au C++, et même dans n'importe quel langage, il faut aller bien au delà de ce qu'on apprend à l''université."

Évidement, j'en sais quelque chose, surtout dans le développement d'application scientifiques,
mais certaine université le font : apprendre le c++ et même Visual Studio !
J'ai moi-même écrit plus de de 80 GO de cours sur le C++, si je dois embauché des ingé,
afin d'éviter qu'il perdent du temps à apprendre tous seuls.

[Uther]

Qu'est ce que tu en sais que je ne maitrise pas le C++ ?
Surtout en disant les modes de débuguage et les assertions ne sont pas le points importants pour assurer la sécurité du code !

Vous savez peut-être faire du C++ mais si vous pensez que le débogage et les assertions sont les points clés pour assurer la sécurité, clairement vous avez quelques des lacunes dans ce domaine.
Les assertions c'est toujours bien de les utiliser, mais ce n'est clairement pas le premier point pour assurer la sécurité car ça ne couvre que les domaines auxquels on pense, or malheureusement les problèmes de sécurité viennent surtout des cas particuliers que l'on oublie.
Quant au débogage, c'est utile pour résoudre des problèmes dont on a connaissance, alors que les problèmes de sécurités sont au contraire des erreurs dormantes. Si on veut s'attaquer aux failles de sécurités, il y a d'autres outils externes bien plus adaptés comme les memory sanitizer, fuzzers, ...

Merci de rester poli et de ne pas faire des affirmations sans savoir.
On ne peut pas entamer une discutions saine et constructive avec des gens comme toi !

Je reste poli et me base uniquement sur ce que vous avez déclaré sur la façon de sécuriser du C++, ce qui montre quand même une manque de connaissances dans la partie sécurité du langage.

Le C++ n'est pas bourré de complexité mais de fonctionnalité, quand on les comprends, qui sont géniales.
Je les utilisent et c'est un énorme avantage par rapport à d'autre langage, en terme de structures comme en terme d'efficacités.

L'un va généralement avec l'autre. En augmentant les fonctionnalités, on augmente également la complexité, surtout quand les les fonctionnalité on un impact large qui peut entrainer des interactions surprenantes avec d'autres. C'est pas pour rien que la plupart des langages qui se sont posé en successeur du C++ (Java, D, Rust, ...) ont visé à limiter les fonctionnalités pour réduire cette complexité induite qui peut amener a de nombreuses erreurs

[Pyramidev]

Le C++ n'est pas bourré de complexité mais de fonctionnalité, quand on les comprends, qui sont géniales.

La complexité du C++ inclut à la fois une richesse en terme de fonctionnalités mais aussi beaucoup de complexité accidentelle, à cause de la rétrocompatibilité avec le langage C et de l'ajout d'un amas d'erreurs de conception.

Par exemple, la coexistence de std::array et du type tableau natif alourdit le langage. Le type tableau natif est un reliquat du langage C.

Autre exemple, std::invoke sert seulement à pallier l'absence de l'Uniform Function Call Syntax quand on fait de la programmation par template.

Il y a aussi des pièges inutiles que le C++ est obligé de garder par rétrocompatibilité, comme le fait que redéfinir le destructeur d'une classe ne désactive pas automatiquement la génération implicite du constructeur de copie et de l'affectation de copie, alors que cela désactive bien la génération implicite du constructeur de mouvement et de l'affectation de mouvement (apparus en C++11).

Quand on étudie Rust après avoir programmé en C++, cela met en lumière beaucoup de complexité accidentelle du C++.

C'est pas pour rien que la plupart des langages qui se sont posé en successeur du C++ (Java, D, Rust, ...) ont visé à limiter les fonctionnalités pour réduire cette complexité induite qui peut amener a de nombreuses erreurs

Ouh là ! Tu peux retirer le langage D de la liste ! Bien au contraire, c'est un langage qui a essayé de cumuler le plus de fonctionnalités possible !

À part ça, je n'aurais pas non plus donné Java en exemple pour chercher à convaincre un développeur C++. À l'époque où je n'avais appris aucun langage "exotique" comme Rust, Haskell ou Common Lisp, C++ était mon langage préféré, car il permettait de combiner le bas niveau du C, la POO du Java et la programmation par templates pour combiner la puissance d'abstraction, les performances et le contrôle sur le typage. Je n'étais pas convaincu par Java que je voyais comme un C++ appauvri pour être accessible par les noobs (ce qui est historiquement bien le cas au départ, surtout à l'époque où Java n'avait même pas les generics).

[Uther]

C'est vrai que dans le cas du C++ une partie de sa complexité vient de l'héritage du C.

Pour ce qui est de la diminution du niveau de complexité de D ou Java, je ne dis pas que c'est une parfaite réussite, mais c'était quand même l'objectif visé à base.
- Le slogan du créateur du D était : "Garder 90% de la puissance du C++ avec seulement 10% de la complexité".
- Si Java te paraissait un C++ tronqué, c'est justement parce que c'était le but : retirer les fonctionnalités qui pouvaient engendrer trop de complexité.
- De même, Rust a volontairement fait le choix de ne pas gérer certaines fonctionnalités de C++ (surcharge, héritage multiple, template metaprogramming...) pour ne pas avoir a assumer la complexité induite.

[bmoraut]

"Vous savez peut-être faire du C++ mais si vous pensez que le débogage et les assertions sont les points clés pour assurer la sécurité, clairement vous avez quelques des lacunes dans ce domaine. "

...

"Je reste poli et me base uniquement sur ce que vous avez déclaré sur la façon de sécuriser du C++, ce qui montre quand même une manque de connaissances dans la partie sécurité du langage."

D'affirmer que j'ai un manques de connaissances dans ce domaine relève que vous êtes bien prétentieux pour vous permettre de juger les autres.

Mais pas de chance, j'ai définie un thèse qui pour écrire un application entièrement sécurisée,
avec des principes révolutionnaires pour le développement de logiciels qui utilise un certains nombre de chose,
comme les modes de débogages, qui permettent d'informer sur l'auto-vérification des logiciels,
(afin de ne pas le ralentir en mode final).

Dans mes plus 10 millions de lignes de codes validées, j'ai actuellement Zéro bugs.
A un tel point, que si un client trouve un bug, je lui offre une licence gratuite.
Cela fait 10 ans que je n'ai jamais rien offert.

Alors désolé, moi aussi je relève dans tes propos que tu es un de ceux qui jouent aux experts, mais qui n'en sont pas.

Tu a un certainement un bon niveau, mais il y a toujours mieux !

Alors reste modeste, et ne préjuge pas des gens, car cela nuit au forum.

Cordialement

[LittleWhite]

Bonjour,

Du coup, par curiosité (et non pas pour valider vos compétences ou autres, car ça, je m'en fout (autrement dit, ce n'est pas mon problème et cela ne va rien me changer), pouvez-vous donner le lien vers un de vos articles scientifiques, et vers le site officiel du logiciel ? Je suis souvent embêté avec le C++ et votre solution pourrait soit éclaircir certaine idée, soit me donner une solution tout en main .

[bmoraut]

Bonjour,

Du coup, par curiosité (et non pas pour valider vos compétences ou autres, car ça, je m'en fout (autrement dit, ce n'est pas mon problème et cela ne va rien me changer), pouvez-vous donner le lien vers un de vos articles scientifiques, et vers le site officiel du logiciel ? Je suis souvent embêté avec le C++ et votre solution pourrait soit éclaircir certaine idée, soit me donner une solution tout en main .

Et bien moi aussi, je n'ai rien à prouver, et par souci de protection de mon travail,
je n'ai donc rien publié.

J'ai bien conscience que c'est une réponse de normand.

Car, quand je consultait vos forums, au départ, il n'y avait pas ce dogmatisme.

On pouvait poser des questions.

Maintenant, on se fait "rabrouer" et quand on essaie d'expliquer quelque chose,
on est "jugé" et traité de tous les noms ("troll" sur certains sites).

Pour ce qui est de la méthode, je vais la déposer en brevet, et former dans un premier temps, si j'en ai besoin, les ingé que j'aurai besoin d'embaucher.

Mais comme vous répondez de façon poli et modeste, je vous révèle quand même un peu le départ de mon travail, ce qui peut vous aider:

Je vous conseil de réfléchir rien que sur le pré fixage des variables, dans votre code,
cela vous réduira 90% de vos bugs. ce qui n'est pas mal au départ.


En effet, on relève des pb de compréhension, comme:
*B
ou l'on ne sait pas si on Multiplie par B ou s'il s'agit de la récupération de la valeur contenue dans la case de pointeur B.

Je ne vous donne pas mes choix, mais si vous prenez le temps d'y réfléchir,
vous écrirez vos règles, qui vous aiderons grandement.

Par exemple,une même donnée/objet peu être exprimé par:
- Sa valeur
- Sa Référence
- Son Pointeur

Cette méthode, je l'ai créé, car je n'ai pas choisi le C++ par "envie" mais bien par une analyse pragmatiste des langages.

Ma méthode m'a permis de réduire de 90% de mes erreurs dès le départ, en partant d'une idée simple, sur une chose déjà présentée,
mais qui n'est plus utilisée:
- le pré fixage des variables.

En partant de l'étude de façon de développer de plusieurs entreprise, j'ai développé cette méthodologie.

Mais je n'en dis malheureuse pas plus sur la totalité de la Méthode pour deux raisons:
- Ma méthode, modestement, qui est peu être trop basée sur ma façon de penser personnelle, n'est peut être pas généralisable
- Pour ne pas "aider" mes concurrents en ce moment.


Mais pour votre curiosité, mon/mes prochain logiciels est/sont grand public, et il est sur le point de sortir.

Dès que j'ai fini le site de présentation, je ne manquerai pas de vous le présenter,
non pas pour "prouver" quoi que se soit, mais bien dans un but lucratif commercial simplement !!!!...

Cordialement

[LittleWhite]

Merci pour la réponse. J'attends de voir alors le produit. N'hésitez pas à le présenter sur le forum, ou bien à m'envoyer un MP pour me rappeler que le site est prêt .

[KsassPeuk]

J'ai bien conscience que c'est une réponse de normand.

Non, c'est une réponse de menteur.

La vérification de programmes et la quête du programme sans bug, c'est un sujet dans le monde de la recherche et du transfert technologique depuis des décennies. Chaque année des thèses et des papiers sur le sujet, on en publie des camions. C'est des milliers de personnes à travers le monde qui bossent dessus avec des succès et des échecs, et le domaine est assez fier des progrès qui ont été faits ces dernières années sur le sujet. Bizarrement, aucun de ces succès n'avance du "on a de la garantie de correction pour plusieurs millions de lignes de code C++". Alors quand type débarque du fond d'un forum en balançant du "non mais moi je suis trop fort, d'ailleurs j'ai réglé le problème sur lequel des milliers de personnes se sont cassés les dents pendant 40 ans, par contre je ne vous fournirai aucune preuve". Oui, on est en droit de dire que cette personne ment, purement et simplement.

A titre personnel, ça me gonfle d'autant plus que je bosse précisément sur ce type de sujet depuis 10 ans. Ce genre de discours, par son absence totale de sérieux, est prompt à créer une réaction chez les développeurs du genre "Haha ! C'est n'importe quoi, on ne pourra jamais ne serait-ce qu'approcher la possibilité d'un logiciel sans bug". Le genre de trucs qui peuvent flinguer le travail de sensibilisation qu'on fait auprès d'eux. et qui efface toutes les subtilités réelles du problème (notamment les liens entre la spécification du logiciel, du langage utilisé, et de l'implémentation du système, et ce qu'on inclut ou non dans la confiance d'un logiciel). Ces développeurs auront d'autant moins de facilité à prendre au sérieux les gens qui bossent réellement sur le sujet, autant pour produire de nouvelles solutions que pour amener ces connaissances dans le monde académique et industriel, et pousser ces solutions vers des usages de moins en moins critiques. Aujourd'hui l'ANSSI a durcis les critères nécessaires pour obtenir certaines certifications (par exemple CC EAL6/7), c'est en grande partie grâce à l'effort important qui a été fournis pendant la dernière décennie pour faciliter la mise en place d'outil de vérification formelle et qui fait qu'aujourd'hui il devient possible de sortir des garanties formelles de correction à code-level pour des softs de l'ordre de quelques dizaines de milliers de lignes. Sans parler du fait que sans aller jusqu'à de tels niveau de fiabilité, on a aujourd'hui un large panel d'outils capable de détecter des problèmes ou garantir leur absence et ce en fonction du type de problème ou de système visé.

[Uther]

D'affirmer que j'ai un manques de connaissances dans ce domaine relève que vous êtes bien prétentieux pour vous permettre de juger les autres.

Écoutez je me base sur le fait que je n'ai entendu aucun expert en sécurité préconiser ça comme première action fondamentale pour sécuriser un code C++. Alors soit vous êtes quelqu'un de très novateur et dans ce cas je m'excuse et j'aimerais beaucoup que vous détaillez comment vous faites, soit il vous manque effectivement des connaissances sur le sujet. Sachez que ça n'a rien d'une insulte : tout le monde à des sujets qu'il connait mieux que d'autres, moi le premier.

Mais pas de chance, j'ai définie un thèse qui pour écrire un application entièrement sécurisée,
avec des principes révolutionnaires pour le développement de logiciels qui utilise un certains nombre de chose,
comme les modes de débogages, qui permettent d'informer sur l'auto-vérification des logiciels,
(afin de ne pas le ralentir en mode final).

Si c'est vraiment le cas, je serais très curieux de lire votre thèse et d'avoir plus de renseignements sur le sujet. A ma connaissance, les systèmes de vérification s'appuient soit sur des preuves formelles, soit de l'analyse statique du code, soit sur de la détection des comportements dangereux à l’exécution, mais qui ne requièrent pas pour autant le fonctionnement en mode débogage.
Si votre système est si efficace grâce aux informations de débogage, je serais très curieux d'en apprendre plus.

Dans mes plus 10 millions de lignes de codes validées, j'ai actuellement Zéro bugs.

Pour le coup, ça m'inquiète plus que ça me rassure. Un logiciel avec zéro failles de sécurité signalées, c'est plus souvent signe d'une mauvaise surveillance des problèmes de sécurité ou d'une rétention des informations de vulnérabilité que d'une grande fiabilité.

Alors désolé, moi aussi je relève dans tes propos que tu es un de ceux qui jouent aux experts, mais qui n'en sont pas.

Je ne prétend pas être un expert, juste connaitre assez le problème de la sécurité en C++ pour savoir que les assertions et surtout le débogage ne sont clairement pas les éléments considérés comme prioritaires pour sa sécurisation.

Alors reste modeste, et ne préjuge pas des gens, car cela nuit au forum.

Je préjuge pas des gens, par contre je juge vos préconisations en matière de sécurisation du code qui sont ... peu orthodoxes pour rester poli. Si vous pouvez m'expliquer réellement comment vous pouvez éviter les failles de sécurité grâce mode débogage, je serais on ne peu plus ravi de revoir mon jugement, mais comme je n'ai jamais entendu parler de rien de tel pour le moment dans le domaine de la sécurité du code, vous me permettrez de rester on ne peu plus sceptique en attendant.

Et bien moi aussi, je n'ai rien à prouver, et par souci de protection de mon travail,
je n'ai donc rien publié.

Il me semble que sauf cas particulier, un travail de thèse est censé être public non ?

J'ai bien conscience que c'est une réponse de normand.

En effet c'est une réponse de normand, mais c'est quand même une réponse qui contredit le propos de base. Vous affirmiez que le C++ est sécurisé, mais comme c'est grâce a une méthode qui ne semble pas vraiment connue des gens du métier, et dont vous ne souhaitez pas nous parler. Même à considérer que vous êtes de bonne foi, il n'en reste pas moins qu'elle n'est à l'heure actuelle pas une solution utilisable par le commun des mortels pour sécuriser ses application C++.

Le peu que vous dites sur votre méthode est basé sur de vielles techniques, très superficielles, qui ont montré leurs limites et dont on est revenu depuis longtemps. C'est très loin de ce qui se fait actuellement dans la sécurité. Si le but était de convaincre de la qualité de vos connaissances en matière de sécurité du code C++, c'est vraiment raté.