Le C++ moderne « ne nous sauvera pas », car il est moins sécurisé que Rust et Swift

Citation:

---

Envoyé par lsbkf

C'est qui lui ? Oh un ingénieur. Si c'est un ingénieur, c'est qu'il a forcément raison !!

---

C'est clair que sortir l'avis d'une personne plutôt lambda, qui n'apporte rien sur un sujet déjà fort connu, je vois pas trop ce que ça fait en news.

Citation:

---

Envoyé par lsbkf

Blague à part, c'est écrit où que C++ recherchait la sécurité ? operator[] ne vérifie pas les dépassements, pauvre petit chou.

---

Le problème est justement que c'est trop facile a utiliser pour quelque chose de potentiellement dangereux. Swift ou Rust permettent les accès non contrôlés si nécessaire pour les performances, mais ils sont explicites pour pousser ceux qui les utilisent à se poser la question de la nécessité de les utiliser.
Un problème récurent en C++ est qu'il y a bien des mécanisme qui permettent une utilisation plus sécurisée, mais eux même introduisent de la complexité et peuvent être mal employés sans que l'on s'en rende compte.

Citation:

---

Envoyé par lsbkf

Et alors, si t'en veux pas tu l'utilises pas, mais après c'est qui qui doit se plaindre de ces applications qui bouffent tout le CPU comme s'ils étaient seuls à s'exécuter.

---

Ce discours valait quand on compare le C++ à des langages managés comme le Python ou le Java. Mais là on parle plutôt de langages compilés moderne sans runtime comme le Rust (et le Swift) qui a prouvé que l'on peut être a la fois sécurisé et avoir des performance identiques au C et C++.

Citation:

---

Envoyé par sergio_is_back

Si on cherche la sécurité à tout prix alors il faut éviter d'écrire une seule de code.... Même dans un langage très cadré un développeur peut induire des biais qui seront acceptés par le compilateur et mèneront à la catastrophe...

---

Bien sur et on peut démarrer un incendie avec un briquet, alors pourquoi ne pas utiliser un lance flamme pour allumer sa cigarette ?
Ce n'est pas parce qu'aucun langage n'est parfait qu'il n'est pas intéressant de considérer leurs avantages particuliers.

Citation:

---

Envoyé par wolinn

On peut toujours construire des exemples pour mettre en évidence la faible sécurisation du langage, mais en pratique, c'est un problème surtout pour les débutants ou les programmeurs peu rigoureux

---

Non c'est clairement un problème qui concerne tous les programmeur. On retrouve en permanence des failles, qui ne seraient pas arrivées avec des langages plus sécurisés, dans tous les navigateurs, OS, et autre programmes critiques, qui ne sont pourtant pas codés par des débutants, et qui sont très surveillés niveau sécularité.

Citation:

---

Envoyé par wolinn

ou peut-être dans des contextes où on demande aux gens de produire du code au kilomètre le plus vite possible et sans grande contrainte pour les performances du produit final.

---

Le "peut-être" me parait inadapté car je ne connais quasiment aucune entreprise où le temps n'est pas une contrainte forte.

Citation:

---

Envoyé par wolinn

Pour ce qui est des 'lambda', c'est une construction nouvelle (bien que ça ait déjà 8 ans), je considère que je n'en maitrise pas encore toutes les subtilités, et donc j'évite simplement les constructions trop audacieuses pour l'instant. Après tout, j'écrivais en C++ presque 20 ans avant que ça existe. Et puis il faut aussi un peu de temps pour avoir confiance dans les compilateurs eux-mêmes.

---

C'est là où la sécurité est aussi utile à la productivité. En Rust (je connais bien moins Swift) on peut utiliser les lambda sans risques. Au pire le compilateur te dira si ça pose le moindre problème de sécurité.

Citation:

---

Envoyé par sebastiano

C'est malheureusement devenu une habitude, un monde de plus en plus binaire alors que, paradoxalement, on a un accès à des méthodes, un savoir, des possibilités infiniment plus grandes que ce qu'ont eu nos ancêtres... c'est le monde, c'est comme ça, on ne peut rien y faire.

---

Je pense que c'est justement un réflexe assez naturel, face à un monde toujours plus vaste au point qu'il peut paraître nous échapper. On peut facilement être tenté de se replier sur ce qu'on connaît, pour avoir un sentiment de sécurité, quitte a passer a coté de beaucoup de choses intéressantes.

Citation:

---

Envoyé par Bousk

En gros ces langages intègrent dans leur compilateur / phase de compilation de l'analyse de code.
C'est cool, mais en C++ tu as des outils externes qui le font également. C'est loin d'être parfait - mais peuvent-ils prétendre que celui intégré à Rust ou Swift (ou n'importe quel autre nouveau langage qui vient clâmer sa sécurité "by design") le soit ? - mais y'a donc pas de manque réel. Après s'ils sont pas utilisés...

---

Les créateur de C++ ont travaillé sur une version les "c++ core guidelines" qui permettent au C++ d'être vérifié statiquement sur l'utilisation de la mémoire. C'est bien, mais niveau garanties ça reste loin de ce que peux faire le Rust qui garantit complètement l'absence d'erreur mémoire et de data race. Le C++ n'a pas été du tout prévu pour ça à la base.

Citation:

---

Envoyé par archqt

Oui et non car comme C est le plus utilisé, forcément c'est aussi celui qui va montrer le plus de failles.
Un peu comme windows qui est nettement moins sécurisé que linux car il a plus de virus...Cela ne prouve rien. Ce qui est plus utilisé montrera forcément plus rapidement et plus souvent des failles.

---

Oui, enfin il est aussi plus utilisé, donc les failles sont mieux documentées et colmatées, ce raisonnement peut aller dans un sens comme dans l'autre. Surtout quand on sait que C++ comme C et Java sont dans le top 5 de popularité dans la majorité des classements, donc ça ne suffit pas à expliquer une différence entre 47% (C), 17% (Java) et 6%(C++)

Salut,

Citation:

---

Envoyé par Uther

Le problème est justement que c'est trop facile a utiliser pour quelque chose de potentiellement dangereux. Swift ou Rust permettent les accès non contrôlés si nécessaire pour les performances, mais ils sont explicites pour pousser ceux qui les utilisent à se poser la question de la nécessité de les utiliser.

---

Il ne faut pas non plus oublier que toute fonctionnalité (et je parle donc aussi de operator[]) ne vaut que par l'utilisation qui en est faite.

Hé bien, je suis désolé, mais moi qui ne suis pas ingénieur, je sais que, par nature, l'utilisateur (et donc ... moi-même le plus souvent) est un imbécile distrait, et, du coup, j'ai pris le pli de ne jamais lui faire confiance.

Je vais donc utiliser operator[] dans deux cas différents :

Dans le premier cas, je sais que je peux faire confiance aux mécanismes de la classe que j'utilise. C'est le cas "classique" du

Code:

---

1 2 3 4 5

std::vector<Type> tab; /* on remplit le tableau à notre guise */ for(size_t i =0; i< tab.size();++i){ /* on utilise tab[i] à notre convenance */ }

---

et qu'il n'y aura pas de problème.

Dans le deuxième cas, je n'ai aucun contrôle sur l'indice qui sera utilisé lors de l'appel à operator[], et je vais donc prévoir que l'utilisateur du tableau a fait une erreur de logique. Mon code ressemblera donc à

Code:

---

1 2 3 4

void foo(std::vector<Type> /* const */ & tab, size_t index){ assert(index<tab.size() && "index out of bound"); /* je peux maintenant utiliser tab[index] en toute sécurité */ }

---

Tu peux tourner les choses comme tu le veux, mes utilisations de operator[] sont safes ;)

Citation:

---

Un problème récurent en C++ est qu'il y a bien des mécanisme qui permettent une utilisation plus sécurisée, mais eux même introduisent de la complexité et peuvent être mal employés sans que l'on s'en rende compte.

---

Heu... tu veux parler de la fonction membre at() de std::vector :question:

Voilà bel et bien une des rares fonctions qui n'auraient jamais du trouver sa place dans la bibliothèque standard; du moins, dans sa version actuelle.

Car il est totalement incohérent d'avoir recours à une exception pour signaler une erreur de logique qui aurait du être corrigée bien avant d'arriver au stade de la production.

Si elle avait utilisé une assertion, susceptible d'être supprimée du code binaire exécutable en production, les choses auraient été différentes ;)

Citation:

---

Ce discours valait quand on compare le C++ à des langages managés comme le Python ou le Java. Mais là on parle plutôt de langages compilés moderne sans runtime comme le Rust (et le Swift) qui a prouvé que l'on peut être a la fois sécurisé et avoir des performance identiques au C et C++.

---

On a toujours bien dit qu'il fallait être particulièrement attentif lorsque l'on décide de coder en C et en C++, car ce sont des langages qui, contrairement à d'autres, mettent énormément le développeur face à ses responsabilités.

Je trouve, quelque part, dommage et surprenant que la personne qui est sensée prendre les responsabilités (car, c'est quelque part le job des ingénieurs) essaye de s'en décharger sur des outils, qui ne seront jamais que cela ;)

Citation:

---

Bien sur et on peut démarrer un incendie avec un briquet, alors pourquoi ne pas utiliser un lance flamme pour allumer sa cigarette ?
Ce n'est pas parce qu'aucun langage n'est parfait qu'il n'est pas intéressant de considérer leurs avantages particuliers.

---

On peut également inverser le raisonnement : bien sur, il n'est pas nécessaire d'utiliser un lance-flammes pour allumer un incendie, un briquet suffit amplement.

Dés lors, ce n'est pas parce que certains langages sont "moins sécurisés" (par rapport aux conneries que les gens sont susceptibles de faire en les utilisant) qu'il faut absolument en chercher d'autres!

Bon dieu, qu'on commence par former correctement les gens, de manière à ce qu'ils soient capables d'utiliser correctement les outils qui leur sont donnés malgré toutes les faiblesses dont ils peuvent souffrir!

Un compilateur, un interpréteur, n'importe quel programme qui fonctionne sur un ordinateur n'est jamais qu'un outil! Cet outil a été développé dans un but bien précis et n'a aucune intelligence par lui-même!

C'est donc à la personne qui utilise cet outil de faire preuve d'un peu d'intelligence lors de son utilisation!

Citation:

---

Non c'est clairement un problème qui concerne tous les programmeur, on retrouve dans tous les navigateurs, OS, ... et autre programmes qui ne sont absolument pas codés par des débutants, et qui sont très surveillés niveau sécurtité, énormément d'erreurs qui ne seraient pas arrivées avec des langages plus sécurisés.

---

Quand tu te coupes avec un couteau en voulant te couper une tranche de saucisson, est-ce la faute du couteau, qui s'est volontairement dirigé vers ton doigt :question:

Bien sur que non! C'est parce que tu as été distrait à un moment qui aurait mérité toute ton attention ;)

Un compilateur -- quel que soit le langage envisagé -- n'est jamais qu'un outil. C'est le couteau que tu utilises pour trancher ton saucisson!

Faut il te faire remarquer que même les programmes codés en Rust (je pense nottemment à Gecko, le moteur utilisé par firefox, bien que je puisse me tromper), qui ne sont pourtant pas codés par des débuttants (pour reprendre tes propres termes) souffrent eux aussi de failles de sécurité ?

Si la seule utilisation d'un outil particulier suffisait à empêcher la moindre faille, tous les langages seraient codés de manière à pouvoir en profiter ;). Mais les failles -- quelle qu'elle soient -- sont toujours dues à "l'interface entre la chaise et le clavier": quel que soit l'outil, quel que soit le langage, si tu l'utilises de manière inappropriée, tu obtiendras un résultat branlant ;)

Quelqu'un disait

Citation:

---

Ce n'est pas parce que je suis un expert que je ne fais pas d'erreurs. J'en fais simplement moins que les autres

Mais elles sont plus graves que celles commises par le "commun des mortels".

---

Citation:

---

C'est la ou le peut être me parait inadapté car je ne connaîs quasiment aucune entreprise ou le temps n'est pas une contrainte forte.

---

Et que penses tu du premier conseil pour gagner du temps qui est ... de prendre son temps, justement lorsque l'on développe quelque chose :question:

Combien de fois ne t'es tu pas heurté à une impossibilité tout droit issue d'une décision inappropriée prise "pour gagner du temps", qui a eu pour effet de t'en faire perdre bien plus que ce que tu n'en a gagné par la suite :question:

Personnellement, j'ai arrêté de les compter ;)

Citation:

---

C'est la ou la sécurité est aussi utile à la productivité. En Rust (je connais bien moins Swift) on peut utiliser les lambda sans risques. Au pire le compilateur te dira si ça pose le moindre problème de sécurité.

---

... A condition que le problème de sécurité que cela pose soit connu.

Car le véritable problème, ce ne sont pas les failles qui sont connues et malgré tout reproduites à l'envi. Ces failles, elles sont encore "relativement" faciles à repérer et à corriger quand elles surviennent.

Le véritable problème, ce sont toutes ces failles qui ne sont pas connues aujourd'hui, mais dont on se rendra compte de l'existence "demain". Ces failles, inconnues à ce jour, il n'y a absolument rien qui puisse t'en prémunir (forcément, vu qu'on n'en a pas encore connaissance), et elles peuvent rester présentes pendant des années avant que l'on ne s'en rende compte. Les exemples ne manquent pas pour nous en convaincre ;)

Citation:

---

Envoyé par koala01

Bon dieu, qu'on commence par former correctement les gens, de manière à ce qu'ils soient capables d'utiliser correctement les outils qui leur sont donnés malgré toutes les faiblesses dont ils peuvent souffrir!

Un compilateur, un interpréteur, n'importe quel programme qui fonctionne sur un ordinateur n'est jamais qu'un outil! Cet outil a été développé dans un but bien précis et n'a aucune intelligence par lui-même!

C'est donc à la personne qui utilise cet outil de faire preuve d'un peu d'intelligence lors de son utilisation!

---

du fait qu'un humain est faillible, on créé des outils pour justement tenter de juguler le coté aléatoire de la défaillance humaine.
peu importe le niveau de compétence de quiconque, un outil sera toujours plus performant pour effectuer une vérification d'un pattern qu'on aura jugé incorrect.

Citation:

---

Envoyé par koala01

Quand tu te coupes avec un couteau en voulant te couper une tranche de saucisson, est-ce la faute du couteau, qui s'est volontairement dirigé vers ton doigt :question:

Bien sur que non! C'est parce que tu as été distrait à un moment qui aurait mérité toute ton attention ;)

---

d'où le fait d'utiliser un outil qui coupera le saucisson à ta place, une meilleure qualité de découpe, une plus grande rapidité etc. etc. et on laisse le cuisinier faire des choses pour lesquelles une machine est encore inadéquate. (enfin si la chose qu'on veut est une amélioration de la qualité globale d'un code, sinon, pas d'outils, pas de guidelines, etc. et dans 2 mois on a un code que personne comprend...)

Citation:

---

Envoyé par koala01

Un compilateur -- quel que soit le langage envisagé -- n'est jamais qu'un outil. C'est le couteau que tu utilises pour trancher ton saucisson!

---

plus le "couteau" sera avancé, moins tu auras de chance de te couper un doigt.

Citation:

---

Envoyé par koala01

Faut il te faire remarquer que même les programmes codés en Rust (je pense nottemment à Gecko, le moteur utilisé par firefox, bien que je puisse me tromper), qui ne sont pourtant pas codés par des débuttants (pour reprendre tes propres termes) souffrent eux aussi de failles de sécurité ?

---

si on va par là, pourquoi faire du c++, retournons à l'assembleur.

Citation:

---

Envoyé par koala01

Si la seule utilisation d'un outil particulier suffisait à empêcher la moindre faille, tous les langages seraient codés de manière à pouvoir en profiter ;). Mais les failles -- quelle qu'elle soient -- sont toujours dues à "l'interface entre la chaise et le clavier": quel que soit l'outil, quel que soit le langage, si tu l'utilises de manière inappropriée, tu obtiendras un résultat branlant ;)

---

pareil que précédemment, je me demande pourquoi on s'amuse à améliorer les choses, je devrais couper mon saucisson au silex, là j'aurais des sensations pures...

bref, il y a tellement à dire, je sais pas si c'est une bonne chose.

Citation:

---

Envoyé par koala01

Tu peux tourner les choses comme tu le veux, mes utilisations de operator[] sont safes ;)

---

En effet c'est tout a fait safe :
- dans le premier cas tu fais la même chose qu'avec un itérateur. Les langages "safe" font eux aussi ça sans contrôle de dépassement.
- dans le second cas tu fais le contrôle de dépassement manuellement.
Au final tu fais la même chose qu'un langage safe, avec plus de code et sans la garantie que ta règle sera bien respectée partout.

Citation:

---

Envoyé par koala01

Heu... tu veux parler de la fonction membre at() de std::vector :question:
Voilà bel et bien une des rares fonctions qui n'auraient jamais du trouver sa place dans la bibliothèque standard; du moins, dans sa version actuelle.
Car il est totalement incohérent d'avoir recours à une exception pour signaler une erreur de logique qui aurait du être corrigée bien avant d'arriver au stade de la production.
Si elle avait utilisé une assertion, susceptible d'être supprimée du code binaire exécutable en production, les choses auraient été différentes ;)

---

Sauf que c'est encore partir du principe que les développeurs sont parfait et ne laissent jamais passer un bug en production. La pratique a prouvé maintes et maintes fois que c'est faux. Et une erreur de mémoire pouvant se transformer en faille de sécurité, avoir la possibilité de lever une exception pour empêcher un comportement potentiellement dangereux en production fait tout à fait sens.

Citation:

---

Envoyé par koala01

On a toujours bien dit qu'il fallait être particulièrement attentif lorsque l'on décide de coder en C et en C++, car ce sont des langages qui, contrairement à d'autres, mettent énormément le développeur face à ses responsabilités.

---

Est-ce que le fait de dire "on vous avais prévenu" est suffisant sachant que l'on sait que l'humain est faillible ?
Dans certains cas peut-être. Quand on vise une certaine de sécurité on veut avoir des garanties, pas uniquement des responsables a blâmer en cas d'erreur.

Citation:

---

Envoyé par koala01

On peut également inverser le raisonnement : bien sur, il n'est pas nécessaire d'utiliser un lance-flammes pour allumer un incendie, un briquet suffit amplement.
Dés lors, ce n'est pas parce que certains langages sont "moins sécurisés" (par rapport aux conneries que les gens sont susceptibles de faire en les utilisant) qu'il faut absolument en chercher d'autres!

---

Heu désolé, mais j'accroche pas du tout au raisonnement dans ce sens. Tu as essayé d'allumer un incendie avec un briquet seul ? A moins de faire exprès, c'est pas si facile que ça, alors qu'avec un lance flamme c'est de ne pas provoquer un incendie qui est difficile.

Donc oui, même si j'ai un lance-flamme a disposition, je vais demander a mon voisin s'il a un briquet pour allumer ma cigarette. Et même si j'ai un langage qui fait le boulot, je ne m'interdit clairement pas de regarder si il y en a un qui peut faire la même chose avec moins de risques.

Citation:

---

Envoyé par koala01

Un compilateur, un interpréteur, n'importe quel programme qui fonctionne sur un ordinateur n'est jamais qu'un outil! Cet outil a été développé dans un but bien précis et n'a aucune intelligence par lui-même!
C'est donc à la personne qui utilise cet outil de faire preuve d'un peu d'intelligence lors de son utilisation!

---

C'est un outil, mais tous les outils ne se valent pas. Si on a un outil qui permet de faire la tache de manière de manière plus sure, il n'y a pas de raison de le mépriser.

Citation:

---

Envoyé par koala01

Quand tu te coupes avec un couteau en voulant te couper une tranche de saucisson, est-ce la faute du couteau, qui s'est volontairement dirigé vers ton doigt :question:
Bien sur que non! C'est parce que tu as été distrait à un moment qui aurait mérité toute ton attention ;)
Un compilateur -- quel que soit le langage envisagé -- n'est jamais qu'un outil. C'est le couteau que tu utilises pour trancher ton saucisson!

---

J'ai croisé pas mal de vieux menuisiers qui avaient perdu des doigts à la scie circulaire. C'est beaucoup plus rare chez les jeunes artisans depuis que l'on a installé des gardes lames sur les scies circulaires.
Le responsable de l'erreur est clairement l’utilisateur de l’outil, mais une fois que tu as désigné ton coupable, ton problème est toujours là.

Citation:

---

Envoyé par koala01

Faut il te faire remarquer que même les programmes codés en Rust (je pense notamment à Gecko, le moteur utilisé par firefox, bien que je puisse me tromper), qui ne sont pourtant pas codés par des débuttants (pour reprendre tes propres termes) souffrent eux aussi de failles de sécurité ?

---

Il y a certes quelques parties de code en Rust qui ont été introduite dans Gecko ces dernières années, mais il est toujours très majoritairement codé en C++.
Mais c'est vrai qu'il serait intéressant de comparer le nombre de failles reportées par langage dans Gecko. Cependant, l'introduction de Rust dans le moteur étant plutôt récente, donc je suis pas certain que la quantité et l'historique soient suffisants pour que les chiffres soient représentatif.

Rust prétend empêcher totalement certains types d'erreur (hors code "unsafe") comme les erreurs mémoire ou les data races et fournit beaucoup de comportement par défaut qui limitent les risques, mais il ne prétends pas éliminer tous les risques de faille.

Citation:

---

Envoyé par koala01

Si la seule utilisation d'un outil particulier suffisait à empêcher la moindre faille, tous les langages seraient codés de manière à pouvoir en profiter ;). Mais les failles -- quelle qu'elle soient -- sont toujours dues à "l'interface entre la chaise et le clavier": quel que soit l'outil, quel que soit le langage, si tu l'utilises de manière inappropriée, tu obtiendras un résultat branlant ;)

---

La encore c'est un raisonnement en tout ou rien. Ce n'est pas parce qu'une technologie ne résout pas tous les problèmes du monde qu'elle n'est pas intéressante.

Citation:

---

Envoyé par koala01

Et que penses tu du premier conseil pour gagner du temps qui est ... de prendre son temps, justement lorsque l'on développe quelque chose :question:

---

Je dirais que c'est un bon conseil, mais que dans la pratique on a jamais le temps de tout faire parfaitement et qu'il y aura forcément a un moment un arbitrage entre le niveau de qualité attendu et le temps a allouer. Et si un langage peut faire gagner du temps en garantissant que certains type d'erreurs sont impossibles, ce temps peut être utilisé pour améliorer la sécurité sur d'autre points.

Citation:

---

Envoyé par Uther

Donc oui, même si j'ai un lance-flamme a disposition, je vais demander a mon voisin s'il a un briquet pour allumer ma cigarette. Et même si j'ai un langage qui fait le boulot, je ne m'interdit clairement pas de regarder si il y en a un qui peut faire la même chose avec moins de risques.

---

Merci pour ta contribution pertinente (et celles des autres aussi!)

Je reviens juste sur ce point de ton argumentation.

Si on considére que l'humain est faillible, les outils (ie les nouveaux langages) le sont aussi, donc le nouveau langage à des failles, peut être pas aux même endroits.

Dans le cas que tu décris, est-ce qu'il ne vaut mieux pas se perfectionner sur un langage, connaitre toutes ses failles et donc savoir les éviter (dans l'idéal); quitte à passer par des normes de programmation, des outils et autres investissements temporels rentable dans le cadre d'un perfectionnement sur une carrière plutôt que de sauter sur un nouveau langage dont une courte veille techno démontre qu'effectivement, les risques identifiés sont gérés par le langage et pour lequel d'autres risques non identifiés surviendront au cours du développement et qu'en tant que non-expert tu ne seras pas capable de repérer à ce moment?

Rappel important à propos du Rust :

En Rust, il y a un ensemble de règles strictes contrôlées à la compilations qui garantissent que le code n'a pas d'erreurs de mémoire.
Dans les cas où ces règles sont trop strictes et où on veut passer outre, on utilise le mot-clef unsafe.
Du coup, on a une vision claire sur les zone de code pour lesquelles on a la garantie qu'il n'y a pas d'erreurs de mémoire et celles où il faut faire attention.

C'est beaucoup plus sécurisé que d'écrire du code C++ sans contraintes et d'exécuter des outils d'analyse de code qui se débrouillent comme ils peuvent.

Citation:

---

Envoyé par stardeath

du fait qu'un humain est faillible, on créé des outils pour justement tenter de juguler le coté aléatoire de la défaillance humaine.
peu importe le niveau de compétence de quiconque, un outil sera toujours plus performant pour effectuer une vérification d'un pattern qu'on aura jugé incorrect.

---

Je ne disconviens absolument pas de la performance des outils. Je dis juste que, plutôt que de se reposer exclusivement sur cette performance, il serait bon que les gens pensent aussi à utiliser ce qui leur sert de cerveau, car, tant qu'ils ne le feront pas, les outils pourront être aussi performants que l'on veut, le risque restera identique.

Citation:

---

d'où le fait d'utiliser un outil qui coupera le saucisson à ta place, une meilleure qualité de découpe, une plus grande rapidité etc. etc. et on laisse le cuisinier faire des choses pour lesquelles une machine est encore inadéquate. (enfin si la chose qu'on veut est une amélioration de la qualité globale d'un code, sinon, pas d'outils, pas de guidelines, etc. et dans 2 mois on a un code que personne comprend...)

plus le "couteau" sera avancé, moins tu auras de chance de te couper un doigt.

---

Je me sens obligé de te contredire sur ce point.
Voici trois exemples qui te démontreront sans problème que tu fais une très lourde erreur en croyant que tu as moins de risques d'accident, même si on s'éloigne un peu des couteaux:

1- Une personne de mes connaissances était occupée à couper des planches avec une scie circulaire. A un moment, elle s'étonne que les dernières planches coupées aient toute une trace rouge qui n'a rien à faire là... jusqu'au moment où elle se rend compte que la dernière phalange de son majeur traine dans la sciure.

Elle ne l'avait pas senti (la coupe avait été trop nette et trop rapide), mais elle y avait perdu son doigt.

2- Il manquait à un de mes profs de menuiserie la dernière phalange de trois doigts, et il ne disposait encore de la "pince" que parce qu'on lui avait greffé le gros orteil à la place du pouce.

Ce prof était occupé à passer le plateau d'une table rond à la toupie, afin de faire une jolie moulure dessus, lorsque le sens du bois s'est -- forcément -- inversé, et que la lame de la touipe s'est "coincée" dans le bois, faisant valser la pièce.

Dans une telle situation, deux réflexes sont possibles : le bon, qui consiste à "tout lâcher", et à laisser la pièce de bois partir à sa guise, et le mauvais, qui consiste à essayer de la retenir. Il avait eu le mauvais, et sa main est donc passée dans les lames de la toupie, qui n'a pas fait la différence d'avec un morceau de bois.

3- Un boucher de mes connaissance était occupé à trancher du saucisson sur sa trancheuse. Comme la taille restante du saucisson était encore assez importante que pour en tirer plusieurs tranche, mais qu'elle était malgré tout "trop petite" que pour utiliser la pièce qui est sensée être utilisée pour pousser la charcuterie contre la trancheuse, il poussait son saucisson à la main. Son pouce était "juste un peu trop" en avant sur le saucisson, et il est passé dans la trancheuse.

Son pouce est désormais beaucoup plus petit que ce qu'il n'était juste avant cet épisode.

J'ai beau chercher, je peux te garantir que personne n'a perdu la moindre phalange, le moindre morceau de doigt, avec un simple rabot à moulurer, avec une simple scie à main, le moindre couteau, à moins que cela n'ait été purement volontaire (et très douloureux) ;) . Par contre, je peux aussi te garantir que de très nombreux menuisiers (pour ne parler que du métier que je connais) qui ont perdu une ou plusieurs phalanges dans les machines qu'ils utilisaient.

Malgré toutes les sécurités que l'on peut mettre aux différents outils, la conclusions est sans appel :

Bien que les outils "évolués" présentent de nombreux avantages, en terme de vitesse, de régularité et de précision sur les outils "basiques", leur utilisation est beaucoup plus risquée, aussi bien en termes de risques qu'en termes de conséquences.

Citation:

---

si on va par là, pourquoi faire du c++, retournons à l'assembleur.

---

Non, parce qu'il y a quand même un aspect essentiel, commun à l'ensemble des langages dits "de troisième génération" : il permettent un niveau d'abstraction bien plus important, et absolument indispensable à l'obtention des résultats que l'on attend de la part de l'ordinateur.

Citation:

---

pareil que précédemment, je me demande pourquoi on s'amuse à améliorer les choses, je devrais couper mon saucisson au silex, là j'aurais des sensations pures...

---

Il faudrait déjà que tu trouves encore un couteau en silex :D

Plus sérieusement, si tu as le choix entre un couteau en bronze (à condition d'en trouver un), un couteau en acier, un en inox et un en céramique. Je comprend que tu sois tenté de prendre celui en céramique. Mais tu devrais quand même te poser la question de savoir si tu en as absolument besoin. Un "simple" couteau en inox (vu que c'est ce qu'on trouve le plus fréquemment de nos jours) ne te suffirait il pas :question: Crois tu vraiment que tu fera des tranches plus fines ou plus égales avec le couteau en céramique :question:

Permets moi très sincèrement d'en douter, car la finesse et la régularité des tranches dépendront d'abord et avant tout de ton aptitude à faire des tranches fines et régulières. Tu pourras avoir le meilleur couteau du monde, si tu n'est pas capable de t'en servir correctement, tu n'obtiendras pas un meilleur résultat qu'avec un couteau "un peu moins bon" ;)

Techniquement, je n'ai pas entendu parler de beaucoup de risques de sécurité dans un langage "sur" qui n'existe pas en C++.
J'ai une impression que tu as une vision très orientée C++ de la sécurisation apportée par le langage. Dans C++, la sécurisation a été apportée principalement en rajoutant des objets sécurisés par dessus une base qui n'est pas sure, ce qui fait que si les objets sont mal utilisés, il peut rester des failles.

Je vais parler pour Rust qui est le cas que je connais le mieux. Il y a aussi des objets qui aident à la gestion mémoire, mais ils reposent sur un langage qui garantit quelles variables ont accès à quelle partie de la mémoire. Si ces objets sont mal utilisés, on aura une erreur de compilation, pas une faille discrète. La mauvaise connaissance de Rust va en effet compliquer la tache du programmeur qui va avoir beaucoup d'erreurs énervantes, mais le risque d'avoir une erreur technique que C++ aurait évité me parait bien faible. Après il restera toujours les erreurs logiques mais il n'y a pas plus ni moins de raison de les commettre en Rust qu'en C++.

Décider du jour au lendemain de réécrire tout son code dans un nouveau langage qu'on ne maitrise pas n'est certainement pas une bonne idée. La quantité de travail nécessaire est potentiellement énorme et n'en vaut peut-être pas la peine au vu des contrainte du projet. Mais considérer un langage plus sur pour un nouveau projet ou une réécriture nécessaire d'une partie d'un projet C++ peut tout a fait se justifier.

Enfin apprendre un langage supplémentaire, particulièrement le Rust qui oblige a bien réfléchir a la façon dont on utilise la mémoire, ne vous rend pas moins bon a utiliser un langage que vous connaissez déjà, bien au contraire.

Citation:

---

Envoyé par AoCannaille

Oui, enfin il est aussi plus utilisé, donc les failles sont mieux documentées et colmatées, ce raisonnement peut aller dans un sens comme dans l'autre. Surtout quand on sait que C++ comme C et Java sont dans le top 5 de popularité dans la majorité des classements, donc ça ne suffit pas à expliquer une différence entre 47% (C), 17% (Java) et 6%(C++)

---

Bien sûr, sauf qu'avec "l'obligation" d'utiliser des pointeurs nus en C, cela facilite l'arrivée de failles. Ce sera plus difficile d'avoir cela en C++ (si on évite les pointeurs nus).
Idem pour les débordements de buffers, en passant par la STL ce sont des problèmes connus et gérés....

Citation:

---

Envoyé par Uther

Je vais parler pour Rust qui est le cas que je connais le mieux. Il y a aussi des objets qui aident à la gestion mémoire, mais ils reposent sur un langage qui garantit quelles variables ont accès à quelle partie de la mémoire. Si ces objets sont mal utilisés, on aura une erreur de compilation, pas une faille discrète.

---

ça marche comment sans ajouter aucune instruction à l’exécution j'ai du mal à comprendre?

Citation:

---

Envoyé par Andarus

ça marche comment sans ajouter aucune instruction à l’exécution j'ai du mal à comprendre?

---

Par exemple, Rust pousse l'idée du RAII jusqu'au bout. En C++, si on lit une variable non initialisée, on a un comportement indéterminé. On peut aussi avoir un comportement indéterminé si on lit un objet dans un moved-from state (quoique ça dépend du type). En Rust, par contre, ce genre d'erreur entraîne une erreur de compilation, car les durées de vies sont plus strictes.

Un autre exemple en C++ est celui où on appelle std::string::c_str() et stocke le résultat dans une variable (appelons-là ptr). Plus tard, si on modifie la chaîne (par exemple avec std::string::append), l'implémentation peut avoir besoin de déplacer la chaîne ailleurs en mémoire. ptr devient alors un dandling pointer et représente une source de danger.
En Rust, par contre, pour toute variable muable, si on garde une référence dessus capable de modifier cette variable, alors cette référence doit être unique, tant qu'elle est accessible. Donc on ne peut pas appeler l'équivalent de std::string::append tant que la chaîne est déjà accessible ailleurs (via ptr). Pour que ça compile, il faut d'abord que ptr ne soit plus accessible. On peut alors appeler l'équivalent de std::string::append. Ce genre de contrôle se fait aussi à la compilation.

Il y a encore d'autres contrôles. Pour plus de détails, je conseille les chapitres suivants de The Rust Programming Language :

• Understanding Ownership,
• Generic Types, Traits, and Lifetimes et
• Fearless Concurrency

au moins tu depends du systeme dexploitation
au moins c chiant a deployer au plus c'est long a développer

maintenant pour faire un simple hello faut avoir la derniere version de dll truc muche :p

deuxieme coup de gueule on apprend plus au dev pour la base de données de nommé correctement leurs tables
c'est pourtant simple
exemple VST_NOM = voiture nom en stock
non eux ils vont mettre ca en stock alors que stock existe pour pieces détachées

rien ne vaut la methode a lancienne, quitte a faire plus ligne de code, et ca peu depend le langage, c'est surtout comment on te lapprend desfois c'est dur a récupérer :p

A chaque langage son usage.
La question n'est pas d'être sauvé ou non par un C++ dit moderne, mais d'être sauvé par le langage qui correspond à ses besoins.
Le C++ a fait ses preuves depuis longtemps dans des domaines et contextes bien précis qui ne sont pas comparables avec ceux d'autres langages.
On constate par contre une multiplication des langages à des fins surtout commerciales sans qu'il y ait d'innovations vraiment significatives.

Citation:

---

Envoyé par Pyramidev

Un autre exemple en C++ est celui où on appelle std::string::c_str() et stocke le résultat dans une variable (appelons-là ptr). Plus tard, si on modifie la chaîne (par exemple avec std::string::append), l'implémentation peut avoir besoin de déplacer la chaîne ailleurs en mémoire. ptr devient alors un dandling pointer et représente une source de danger.
En Rust, par contre, pour toute variable muable, si on garde une référence dessus capable de modifier cette variable, alors cette référence doit être unique, tant qu'elle est accessible. Donc on ne peut pas appeler l'équivalent de std::string::append tant que la chaîne est déjà accessible ailleurs (via ptr). Pour que ça compile, il faut d'abord que ptr ne soit plus accessible. On peut alors appeler l'équivalent de std::string::append. Ce genre de contrôle se fait aussi à la compilation.

---

Je suis complètement d'accord sur le fait que Rust apporte des fonctionnalités très intéressantes concernant la gestion mémoire. Par contre, je trouve cet exemple assez mal choisi : c_str n'est pas du C++ moderne ni même du C++. Pour moi, ça fait partie de la couche de compatibilité C bas-niveau telle qu'on pourrait l'avoir dans un bloc unsafe de Rust, où justement les avantages de Rust ne s'appliquent pas vraiment.

Hello, je me suis inscrit juste pour répondre à ce message.

A titre d'expérience, j'utilise un allocateur de debuggage en C++. Chaque allocation mémoire est tracée et si il y a oubli d'un delete, mon programme me le dit avec le numéro de ligne et l'allocation qui à été oubliée. Sur un assez gros programme, j'ai fais deux erreurs d'allocation. Pas bien réveillé, en déplaçant les allocations à un autre endroit et en oubliant de déplacer les deletes avec. L'allocateur m'a rappelé à l'ordre en me disant vous avez oublié de libérer deux blocs a tel endroit.

Sous VC++, l'allocateur de debuggage, vous mettez ça dans votre stdafx.h puis vous remplacez vos new par DBG_NEW.

Code:

---

1 2 3 4 5 6 7 8 9 10

#if _DEBUG #define _CRTDBG_MAP_ALLOC #include <crtdbg.h>   #ifdef _DEBUG #define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ ) #else #define DBG_NEW new #endif

---

Sinon, j'utilise pas les shared_ptr pour diverses raisons, si je me trompe pas, par exemple, il aura fallu attendre la v17 pour que shared ptr prenne en charge les tableaux.
Mais je les utilise pas pour d'autres raisons, parce que quand on fait une allocation on doit savoir ou et quand on en a plus besoin, ce qui élimine de facto le besoin d'un shared_ptr. Si il y a besoin c'est un peu inquiétant.

A coté de ça, j'utilise pas/peu non plus les notions "moderne" du C++. Je me limite aux containers, aux fonction de tri, peut être un ou deux autre trucs que j'ai oublié aussi.
Mais même les lambda que je trouvais sympa à la base j'évite de les utiliser. Je crois on pourrait appeler mon style de programmation du C avec des classes plutôt que C++ ou C++ moderne. Je préfère faire attention à ce que mes programmes restent lisibles et tout de suite compréhensible 6 mois plus tard même pour un programmeur Java. Ce qui n'est plus possible avec du C++ moderne, selon moi. Même pour un programmeur C ca va devenir compliqué.

Donc, en effet, je raffole pas de ce C++ moderne, surtout dans ses dernières versions. Je trouve qu'il ajoute de la complexité à la complexité. Sans parler des messages d'erreurs qui font 3 pages. J'aurais préféré qu'on fasse évoluer le langage lui même, par exemple en ajoutant de la granularité, des pointeurs de fonctions membre directement intégrés au langage sans passer par la lib, des property comme le C# et pourquoi pas une lib graphique plutôt que de charger la lib de notions de plus en plus techniques. Ca me fait penser que j'utilise pas non plus les std::string. Bon je suis programmeur win32 c'est 100% de pointeurs et autres LPCTSTR et c'est mieux je trouve.

Si ça persiste je pense pas aller vers du Rust, du Swift ou du GO mais plutôt vers le C. Un langage assez simple pour peu qu'il soit correctement écrit et qui donne accès à tout, par contre ça me fera revenir dans la douleur à un langage sans classes et sans namespace, la c'est dur mais qui a dit que la programmation c'était facile?

Bonne programmation à tous
Cordialement,

Citation:

---

Envoyé par yrazet

Hello, je me suis inscrit juste pour répondre à ce message.

---

Bienvenue sur le forum ;)

Citation:

---

A titre d'expérience, j'utilise un allocateur de debuggage en C++. Chaque allocation mémoire est tracée et si il y a oubli d'un delete, mon programme me le dit avec le numéro de ligne et l'allocation qui à été oubliée. Sur un assez gros programme, j'ai fais deux erreurs d'allocation. Pas bien réveillé, en déplaçant les allocations à un autre endroit et en oubliant de déplacer les deletes avec. L'allocateur m'a rappelé à l'ordre en me disant vous avez oublié de libérer deux blocs a tel endroit.

Sous VC++, l'allocateur de debuggage, vous mettez ça dans votre stdafx.h puis vous remplacez vos new par DBG_NEW.

Code:

---

1 2 3 4 5 6 7 8 9 10

#if _DEBUG #define _CRTDBG_MAP_ALLOC #include <crtdbg.h>   #ifdef _DEBUG #define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ ) #else #define DBG_NEW new #endif

---

---

On l'a tous fait au moins une fois :D

Mais, pour être honnête, il y a "à boire et à manger" dans la pratique...

Il y a, en effet, d'énormes avantages à utiliser un tel système (ne serait-ce que le fait que l'on puisse suivre les allocations de mémoire), mais il y a d'énormes inconvénients, qui découlent tous d'un fait tout bête : tu utilises une fonction qui t'est propre (DBG_NEW), ce qui implique:

1. que les allocations "tièrces" (comprends : exécutée en dehors de ton projet) ne sont pas prises en compte
2. qu'il est impossible, même si ton projet est correctement "saucissonné", de ne récupérer qu'une seule classe, une seule paire de fichiers d'en-tête (*.h / *.hpp) et d'implémentation (*.cpp) pour "autre chose" sans soit avoir besoin d'y ajouter <crtdb.h> (quid si un autre système similaire existe déjà dans l'autre projet :question:) ou sans avoir besoin d'en modifier le code pour pouvoir l'utiliser

Ce n'est -- bien sur -- absolument pas catastrophique, mais, disons que cela présente malgré tout un frein de taille à la réutilisation potentielle de ton code ;)

Citation:

---

Sinon, j'utilise pas les shared_ptr pour diverses raisons, si je me trompe pas, par exemple, il aura fallu attendre la v17 pour que shared ptr prenne en charge les tableaux.

---

Tu as raison, mais le fait est que, de toutes façons, le couple std::shared_ptr et std::weak_ptr ne devrait pas être ton choix "par défaut".

"Par défaut" (comprends: si tu n'as aucune raison de faire autrement), le meilleur choix de pointeur intelligent est d'utiilser std::unique_ptr, ne serait-ce que pour ne pas avoir à payer le coût d'un comptage de référence qui s'avère bien souvent inutile ;)

En outre, "la logique" voudrait que l'on n'utilise l'allocation dynamique que pour les classes dites "à sémantique d'entité", étant donné que l'on dispose déjà de deux classes (std::vector et std::array) pour représenter la notion de "tableaux", et que ces deux classes fournissent (lorsqu'elles sont correctement utilisées, cela va de soi) toutes les garanties nécessaires.

Citation:

---

Mais je les utilise pas pour d'autres raisons, parce que quand on fait une allocation on doit savoir ou et quand on en a plus besoin, ce qui élimine de facto le besoin d'un shared_ptr. Si il y a besoin c'est un peu inquiétant.

---

Tu as raison sur ce point de vue.

Malheureusement, les choses ne sont pas aussi simples que cela, pour une simple et bonne raison : C++ est un langage à exception.

Un code aussi simple

Code:

---

std::cout<<"hello world";

---

pouvant parfaitemet lancer une exception, il est très difficile de prévoir tous les chemins d'exécution qui pourraient nécessiter la libération d'une ressource allouée de manière dynamique.

C'est la raison de la mise en place de ce que l'on appelle des "capsules RAII" (dans la catégorie desquelles on trouve std::unique_ptr et std::shared_ptr): ce sont des données qui se trouvent -- a priori -- sur la pile, qui sont donc automatiquement détruite lorsque l'on sort de la portée dans laquelle elles ont déclarées (comme n'importe quelle donnée sur la pile), et provoquent donc automatiquement la libération de la ressource allouée de manière dynamique.

Citation:

---

A coté de ça, j'utilise pas/peu non plus les notions "moderne" du C++. Je me limite aux containers, aux fonction de tri, peut être un ou deux autre trucs que j'ai oublié aussi.

---

A l'exception des pointeurs intelligents, dont on vient de parler, c'est une approche que l'on peut comprendre, mais qu'on ne va sans doute pas plébiciter :aie:

La plupart des fonctionnalités apportées par C++11 et ultérieures permettent en effet de rendre le code plus sur (là où il y avait un manque flagrant de sécurité) et au compilateur de générer du code plus rapide.

La déclaration des fonctions membre comme étant delete, par exemple, nous permet d'écrire un code proche de

Code:

---

1 2 3 4 5 6 7 8 9 10

class MyEntity{ public: /* une classe ayant sémantique d'entité ne peut être ni copiée ni assignée */ MyEntity(MyEntity const &) = delete; MyEntity& operator=(MyEnity const &) = delete; /* le destructeur d'une classe ayant sémantique d'entité sera soit public et virtuel, soit   * protected et non virtuel   */ virtual ~MyEntity() /* = default */; };

---

là où il aurait fallu attendre l'édition de liens pour se rendre compte d'un éventuel problème avec un code proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

/* Avant C++11, on aurait travaillé de la sorte */ class MyEntity{ public: /* le destructeur d'une classe ayant sémantique d'entité sera soit public et virtuel, soit   * protected et non virtuel   */ virtual ~MyEntity() private: /* on aurait déclaré le constructeur de copie et l'opérateur d'affectation   * dans l'accessibilité privée, et ON NE LES AURAIT SURTOUT PAS   * IMPLEMENTES   */ MyEntity(MyEntity const &); MyEntity & operator=(MyEntity const &); }

---

Pire encore, si, par distraction, le développeur de MyEntity venait à fournir une implémentation du constructeur de copie et / ou de l'opérateur d'affectation, cela aurait pu occasionner quelques bugs très spécifiques ;)

De même, les mots clé override et final obligent le compilateur à s'assurer que les fonctions pour lesquelles ont redéfini le comportement existent bel et bien dans la classe de base, et qu'elles sont bel et bien virtuelles.

Il suffit de "si peu" (une étoile ou une esperluette en plus ou en moins pour le type de retour ou pour la déclaration d'un paramètre, par exemple) pour que l'on assiste à une surcharge de la fonction (qui n'est pas virtuelle) au lieu d'assister à une redéfinition de la fonction virtuelle que ce serait vraiment très dommage de ne pas forcer le compilateur à faire cette vérification ;)

Citation:

---

Mais même les lambda que je trouvais sympa à la base j'évite de les utiliser.

---

Là encore, c'est une approche que l'on peut comprendre...

Après tout, nous nous en sommes passé pendant 13 ans, en créant au besoin un foncteur spécifique à l'intérieur d'une fonction hein :question:

Cependant, le système avait malgré tout ses limites... Et ce sont ces limites qui ont été repoussées grâce aux expressions lambda ;)

Il est -- encore une fois -- dommage que tu restes "bloqué" par des limites qui ont pu être abolies par la nouvelle norme ;)

Citation:

---

Je crois on pourrait appeler mon style de programmation du C avec des classes plutôt que C++ ou C++ moderne.

---

Ca, c'est sans doute le plus gros problème!!!

Le C with classes n'a été développé à la base que pour servir de "fondation" au C++, parce qu'il fallait bien avoir "quelque chose" qui soit susceptible d'être compris par un compilateur C pour pouvoir générer le compilateur C++.

Mais, dés le départ, C et C++ ont été des langages différents, même si les premiers utilisateurs de C++ n'en avaient pas forcément conscience. Et, même si C++ a tout fait (du moins, au début) pour assurer une "certaine compatibilité" avec le C, la différence entre les deux langages n'a pu que s'amplifier avec le temps ;)

Citation:

---

Je préfère faire attention à ce que mes programmes restent lisibles et tout de suite compréhensible 6 mois plus tard même pour un programmeur Java.

---

Et tu as encore une fois bien raison!

Seulement, la manière dont tu t'y prend n'est peut-être pas la bonne ;)

Citation:

---

Ce qui n'est plus possible avec du C++ moderne, selon moi.

---

C'est là que tu te trompe ;)

Les expression lambda (par exemple) sont apparues en 2006 en java. Tu ne dois donc pas avoir peur qu'un développeur java ne comprenne pas une expression proche de

Code:

---

[](Type t)->bool{/* ce qu'il faut faire */};

---

, même s'il y a une paire de crochets en plus ;)

Citation:

---

Même pour un programmeur C ca va devenir compliqué.

---

Ah oui, en C, les expressions lambda n'existent à mon sens pas encore ;)

Mais C++ est beaucoup plus proche (malgré toutes les différences qu'il a par rapport à java) de java que de C, contrairement à ce que l'on croit ;)

Citation:

---

Donc, en effet, je raffole pas de ce C++ moderne, surtout dans ses dernières versions.

---

Chaqun verra midi à sa porte ;)

Citation:

---

Je trouve qu'il ajoute de la complexité à la complexité.

---

Au contraire, je te dirais bien que les versions de C++ d'après 2011 font tout pour essayer de supprimer une partie de la complexité, ou, du moins, pour arriver à en cacher une grosse partie ;)

Citation:

---

Sans parler des messages d'erreurs qui font 3 pages.

---

Les messages d'erreurs qui font trois pages ont toujours été dus à l'approche générique du C++. Enfin, je vais préciser:

Quand une seule erreur provoque un message d'erreur de trois pages, tu dois t'attendre à ce que ce soit du à une erreur en programmation générique.

Que tu aies 120 "faux positifs" après la seule erreur réelle de ton code, parce que le compilateur a "perdu les pédales" mais qu'il a malgré tout essayé de terminer le traitement de ton fichier d'implémentation, ca ca a toujours été ;)

Mais même là, les nouvelles fonctionnalités tendent de résoudre le problème (je pense, entre autres, au static_assert) en faisant apparaitre en priorité un message plus clair et plus précis ;).

Citation:

---

J'aurais préféré qu'on fasse évoluer le langage lui même, par exemple en ajoutant de la granularité,

---

Je suis mal réveillé, je ne vois pas trop de quoi tu parles...

Citation:

---

des pointeurs de fonctions membre directement intégrés au langage sans passer par la lib,

---

Cela existe depuis toujours, même si ce n'est pas très utilisé

Citation:

---

des property comme le C#

---

Quoi :question: des get et des set automatiques :question: Quelle horreur !!!!

Citation:

---

et pourquoi pas une lib graphique

---

Figure toi qu'il semblerait que ce soit en cours

Citation:

---

plutôt que de charger la lib de notions de plus en plus techniques.

---

La seule notion spécifique à la bibliothèque qui ait été rajoutée (en dehors de certaines classes dont on avait un réel besoin, comme les thread, la gestion du temps ou l'alléatoire), ca a été la sémantique de déplacement.

Et même la sémantique de déplacement représentait un besoin vraiment réel en termes de performances ;)

Citation:

---

Ca me fait penser que j'utilise pas non plus les std::string. Bon je suis programmeur win32 c'est 100% de pointeurs et autres LPCTSTR et c'est mieux je trouve.

---

Encore une fois, chacun verra midi à sa porte, mais LPCSTR

1. c'est du C
2. c'est absolument non portable

Dans un monde où windows n'est clairement plus le seul système d'exploitation utilisé, le deuxième point est particulièrement dommage ;)

Au passage, pourquoi ne pas te tourner vers Qt, si tu fait des applications graphiques :question: Il te suffirait d'avoir un compilateur croisé pour que tes applications fonctionnent également sous linux et ou sous mac... cela ne t'intéresse pas :question:

Citation:

---

Si ça persiste je pense pas aller vers du Rust, du Swift ou du GO mais plutôt vers le C.

---

Et tu te retrouveras avec un tas de problèmes encore bien pire que ceux auxquels tu es confronté avec java ou avec C++ :aie:

C a l'énorme avantage d'être la "franqua lingua" du développement. Mais, si tu a l'habitude du C#, ce n'est vraiment pas pareil ;)

Citation:

---

Un langage assez simple pour peu qu'il soit correctement écrit et qui donne accès à tout, par contre ça me fera revenir dans la douleur à un langage sans classes et sans namespace, la c'est dur mais qui a dit que la programmation c'était facile?

---

Et pourtant, tu choisirais le seul langage qui ne propose à la base ni classes ni espaces de noms :aie:

Citation:

---

Bonne programmation à tous
Cordialement,

---

Pareillement ;)

C'est marrant, maintenant que je vous ai lu je ne peux pas m’empêcher de m'imaginer avec les 20 doigts en moins tronçonnés par une mauvaise utilisation de la sémantique de déplacement, et des phalanges sanguinolentes qui traînent un peu partout dans une mémoire encombrées par des tranches de saucissons desséchées et des tartines de lambdas, au milieu des miettes d'un chronomètre atomisé par une mécompréhension de la STL.
Pour autant, je peux pas m’empêcher de penser que c'est juste une phase d'adolescence programmée, et que quand je serai grand ...