Tes précisions sont pertinentes, mais ce n’est pas tout à fait ce qu’il reproche au C++ (je suis aussi tombé dans le même piège). Par exemple, pour le premier exemple, ce n’est pas le fait qu’il n’utilise pas le auto le problème (et aussi accessoirement un using namespace std ne fait pas de mal, même si déconseillé au débutant, j’estime qu’à partir d’un certain niveau c’est indispensable). Son reproche principal est le fait que le C++ ne vérifie pas que son vector utilise des éléments ordonnables.
Donc tu ne réponds pas vraiment au fond du reproche. On pourrait t’en tenir grief. Pourtant son reproche est réellement de mauvaise foi : le C++ possède une structure adaptée, map pour les éléments ordonnables, mais aussi unordered_map, pour les éléments qui peuvent recevoir une fonction de hash, et ce n’est que dans le pire des cas qu’on utilise un vector (éléments comparés un à un avec operator== pouah l’efficacité algorithmique, et je parie que c’est ce que dira en substance le long message pas-si-incompréhensible typique d’une compilation C++). En plus, on peut faire beaucoup de tests à la compilation sur la nature des éléments instantiés en template, avec les traits (je ne sais pas comment traduire). Clair que c’est pas à la portée du premier venu, mais ça existe.
Le C++ apporte énormément de souplesse et de flexibilité. La contrepartie c’est une complexité du langage, que personne ne remettra en cause j’espère. C’est un choix à faire en fonction du projet. Ceci dit, j’apprécie le C++ pour cette raison. Et laissons donc en plan les complexés de la quéquette qui veulent absolument prouver au monde entier (削除) qu’ils ont la plus grosse (削除ここまで) que leur langage est le meilleur de tous.
Pour le deuxième exemple : complètement bidon, y’a les smart pointers.
Pour le troisième : WTF ?! Le mec retourne un pointeur sur une variable locale. Dès qu’il sort de la portée, il perd l’adresse. En fait l’a de la chance de ne pas se prendre un segmentation fault en pleine gueule. Si on compile avec -O3, on a 1, 2 en sortie sur ma machine :) mais ce serait une mauvaise pratique.
Pour le quatrième : Mouai. Bof. Joker.
Pour le cinquième : particulièrement obscure. Beaucoup de choses me chagrine, et ni l’envie ni le temps de creuser.
Je croyais que , est un opérateur et qu’il a pour particularité en C++ de ne pas imposer un ordre d’exécution. C’est un exemple classique de piège (habituellement on dit au débutant que les arguments lors d’un appel de fonction sont évalués de manière désordonnée). Quelqu’un pour confirmer ce que j’avance ?
Dans tous les cas, j’évite cette syntaxe, y compris en argument d’appel si je sais qu’il y a des effets de bord. Par exemple si j’ai une ligne de type c = f(g(a),h(b)); je vérifie que g et h sont des fonctions pures (le résultat dépend exclusivement de l’argument).
De plus : smart pointers banane ! Nan mais sérieux quoi... le copie en surface vs. copie en profondeur c’est la base. Si on veut pas s’emmerder avec ça, on utilise la classe de pointeur adaptée à ce qu’on veut faire (unique, par référence, le truc bâtard d’avant 11, etc.).
On a les mot-clefs delete et default. Faut pas hésiter à être explicite en cas de doute sur le quintuplet (constructeur, destructeur, constructeur par copie, par référence, opérateur d’affectation) parce que les règles les concernant sont chiantes à retenir lorsqu’on a héritage.
The code builds and runs with no error. Gni, je ne connais pas le Rust, ce serait sympa de me dire comment un code qui affecte un objet à une variable, mais sans avoir de constructeur par copie et/ou un opérateur d’affectation peut s’en sortir. En fait je soupçonne le Rust de faire une copie par référence. Quelqu’un qui connaît le langage peut confirmer ? Parce qu’en l’état son exemple est obscur. Et faire une copie par référence sans le dire, c’est faire caca dans le dos du programmeur (cool quand je modifie un objet d’une variable a ça modifie aussi l’autre _b !). C’est un problème dans les langages de haut niveau, parce que pour cette raison on se reprend leur soit-disante simplicité en pleine gueule. Faut apprendre par cœur les règles d’affectation du langage en question. Et faut savoir aussi quel système ils utilisent pour la mémoire : en Python j’ai cru comprendre que c’est un bête compteur de référence (confirmation ?), ce qui pose quelques soucis, on peut aussi avoir une usine à gaz (je ne désignerai pas de coupable).
Pour le sixième : no comment.
Septième : RTFM (section "je ne modifie pas un vecteur que j’itère", point) Quelque soit le langage, c’est casse-gueule ce truc, et faut faire attention quand on part sur des algos "en place".
Huitième, neuvième. no comment.
Le reste : pas le temps.
Le C++ est un langage compliqué, mais c’est pas une raison pour l’abattre alors qu’il ne se débat plus, et ceci en propageant précisément les mauvaises pratiques avec une mauvaise foi carabinée pour démontrer ce que tout le monde sait déjà.
C’est pas le seul lien donné dans le journal à être un troll... Le dernier est particulièrement poilu : les yankee découvrent que les chintoks ne font pas que manger du riz. Allélouïa ! J’aime bien aussi la fusion froide... puis c’est de saison (Père Noël, rêverie d’enfants).
[^] # Re: Comparaison ?
Posté par NicolasG . En réponse au journal Journal Bookmark #2. Évalué à 2.
Tes précisions sont pertinentes, mais ce n’est pas tout à fait ce qu’il reproche au C++ (je suis aussi tombé dans le même piège). Par exemple, pour le premier exemple, ce n’est pas le fait qu’il n’utilise pas le
autole problème (et aussi accessoirement unusing namespace stdne fait pas de mal, même si déconseillé au débutant, j’estime qu’à partir d’un certain niveau c’est indispensable). Son reproche principal est le fait que le C++ ne vérifie pas que son vector utilise des éléments ordonnables.Donc tu ne réponds pas vraiment au fond du reproche. On pourrait t’en tenir grief. Pourtant son reproche est réellement de mauvaise foi : le C++ possède une structure adaptée, map pour les éléments ordonnables, mais aussi unordered_map, pour les éléments qui peuvent recevoir une fonction de hash, et ce n’est que dans le pire des cas qu’on utilise un
vector(éléments comparés un à un avec operator== pouah l’efficacité algorithmique, et je parie que c’est ce que dira en substance le long message pas-si-incompréhensible typique d’une compilation C++). En plus, on peut faire beaucoup de tests à la compilation sur la nature des éléments instantiés en template, avec les traits (je ne sais pas comment traduire). Clair que c’est pas à la portée du premier venu, mais ça existe.Le C++ apporte énormément de souplesse et de flexibilité. La contrepartie c’est une complexité du langage, que personne ne remettra en cause j’espère. C’est un choix à faire en fonction du projet. Ceci dit, j’apprécie le C++ pour cette raison. Et laissons donc en plan les complexés de la quéquette qui veulent absolument prouver au monde entier
(削除) qu’ils ont la plus grosse (削除ここまで)que leur langage est le meilleur de tous.Pour le deuxième exemple : complètement bidon, y’a les smart pointers.
Pour le troisième : WTF ?! Le mec retourne un pointeur sur une variable locale. Dès qu’il sort de la portée, il perd l’adresse. En fait l’a de la chance de ne pas se prendre un segmentation fault en pleine gueule. Si on compile avec -O3, on a 1, 2 en sortie sur ma machine :) mais ce serait une mauvaise pratique.
Pour le quatrième : Mouai. Bof. Joker.
Pour le cinquième : particulièrement obscure. Beaucoup de choses me chagrine, et ni l’envie ni le temps de creuser.
Je croyais que
,est un opérateur et qu’il a pour particularité en C++ de ne pas imposer un ordre d’exécution. C’est un exemple classique de piège (habituellement on dit au débutant que les arguments lors d’un appel de fonction sont évalués de manière désordonnée). Quelqu’un pour confirmer ce que j’avance ?Dans tous les cas, j’évite cette syntaxe, y compris en argument d’appel si je sais qu’il y a des effets de bord. Par exemple si j’ai une ligne de type c = f(g(a),h(b)); je vérifie que g et h sont des fonctions pures (le résultat dépend exclusivement de l’argument).
De plus : smart pointers banane ! Nan mais sérieux quoi... le copie en surface vs. copie en profondeur c’est la base. Si on veut pas s’emmerder avec ça, on utilise la classe de pointeur adaptée à ce qu’on veut faire (unique, par référence, le truc bâtard d’avant 11, etc.).
On a les mot-clefs delete et default. Faut pas hésiter à être explicite en cas de doute sur le quintuplet (constructeur, destructeur, constructeur par copie, par référence, opérateur d’affectation) parce que les règles les concernant sont chiantes à retenir lorsqu’on a héritage.
The code builds and runs with no error.Gni, je ne connais pas le Rust, ce serait sympa de me dire comment un code qui affecte un objet à une variable, mais sans avoir de constructeur par copie et/ou un opérateur d’affectation peut s’en sortir. En fait je soupçonne le Rust de faire une copie par référence. Quelqu’un qui connaît le langage peut confirmer ? Parce qu’en l’état son exemple est obscur. Et faire une copie par référence sans le dire, c’est faire caca dans le dos du programmeur (cool quand je modifie un objet d’une variable a ça modifie aussi l’autre _b !). C’est un problème dans les langages de haut niveau, parce que pour cette raison on se reprend leur soit-disante simplicité en pleine gueule. Faut apprendre par cœur les règles d’affectation du langage en question. Et faut savoir aussi quel système ils utilisent pour la mémoire : en Python j’ai cru comprendre que c’est un bête compteur de référence (confirmation ?), ce qui pose quelques soucis, on peut aussi avoir une usine à gaz (je ne désignerai pas de coupable).Pour le sixième : no comment.
Septième : RTFM (section "je ne modifie pas un vecteur que j’itère", point) Quelque soit le langage, c’est casse-gueule ce truc, et faut faire attention quand on part sur des algos "en place".
Huitième, neuvième. no comment.
Le reste : pas le temps.
Le C++ est un langage compliqué, mais c’est pas une raison pour l’abattre alors qu’il ne se débat plus, et ceci en propageant précisément les mauvaises pratiques avec une mauvaise foi carabinée pour démontrer ce que tout le monde sait déjà.
C’est pas le seul lien donné dans le journal à être un troll... Le dernier est particulièrement poilu : les yankee découvrent que les chintoks ne font pas que manger du riz. Allélouïa ! J’aime bien aussi la fusion froide... puis c’est de saison (Père Noël, rêverie d’enfants).