Discussion :

[emmesse]

bonjour,

que pensez-vous de ce livre:
Programmer en langage C++ 9e édition: Couvre les versions C++11, C++14 et C++17 de la norme Broché – 19 octobre 2017

[mintho carmo]

Les delannoy sont décriés depuis des années pour les mauvaises pratiques qu'il donne (approche historique du C). Les nouvelles normes semblent etre un ajout en annexes, ce n'est pas une réécriture. Donc a eviter a mon avis.

[JolyLoic]

Lors d'un meetup C++, j'ai montré sans dire d'où ils venaient des codes extraits de la dernière édition de ce livre, en en proposant un revue de code. Les critiques se sont mises à pleuvoir dans tous les sens (et ce n'était pas que stylistique, certains étaient de vrais bugs), et quand à la fin j'ai indiqué que ces exemples venaient d'un livre, j'ai lu des spasmes nerveux sur les visages de ceux qui connaissaient cet auteur, et de la consternation sur ceux qui le découvraient ainsi.

Et je n'ai pas cherché longtemps ces exemples, c'étaient littéralement les premiers exemples de code que j'ai ouverts.

J'ai aussi lu un peu du contenu de ce livre (édition 8, disponible à mon travail, mais le sommaire de la 9 est identique). Dire que le livre couvre les normes récentes est à la limite de l'escroquerie. Ajouter 10 pages en fin d'un bouquin qui parle mal du C++98 n'est fera pas un bouquin à jour sur la norme C++11 ou 17...

La manière de programmer a totalement changé, et l'approche de ce bouquin ne permettra pas de devenir un bon développeur C++. Je déconseille très fortement ce livre.

Un petit exemple, issu d'un autre livre du même auteur, mais qui je pense devrait parler même à quelqu'un ne connaissant pas encore le C++ (code consultable là):

Code :

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

1
2
3
4
5
6
7
8
9
10
#include <iostream>
using namespace std ;
main()
{ 
  int nombre, carre ;
  cout << "donnez un nombre : " ;
  cin >> nombre ;
  carre = 2 * nombre ;
  cout << "voici son carre : " << carre ;
}

Il s'agit du premier exemple en C++du bouquin, et on peut citer en vrac :
- Déclaration de la fonction main incorrecte (il manque un type de retour int)
- Utilisation de variable non initialisées totalement déconseillée (il aurait mieux valu écrire directement int carre = 2 * nombre; qui initialise la variable au moment de sa déclaration)
- Confusion entre nombre*nombre et nombre*2 !
- Manque un retour charriot à la fin

Ça fait beaucoup pour un si petit programme...

[Luc Hermitte]

Une petite parenthèse --n'ayant rien à rajouter à l'intervention de Loic, hormis peut-être : "les archives sont vos amies"

- Utilisation de variable non initialisées totalement déconseillée (il aurait mieux valu écrire directement int carre = 2 * nombre; qui initialise la variable au moment de sa déclaration)

Je suis bien sûr totalement d'accord pour la définition retardée.
Pour ce qui est de ne pas initialiser, attention de ne pas tomber dans le travers fort trop répandu de

Code :

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

1
2
3
int carre = 0;
du code...
carre =  2 * expression

C'est une recommandation assez classique qui accompagne la transposition des pratiques héritées du Pascal, Fortran... et autres langages similaires au monde du C++: on déclare tout, puis on initialise par précaution, puis on travaille pour de vrai.

Je suis, aujourd'hui, persuadé que cette pratique est la pire du lot.

Le problème est que si dans "du code...", la valeur de "carré" venait à être utilisée, on utiliserait une valeur qui n'aura certainement pas le moindre sens. En n'initialisant pas, deux familles d'outils peuvent nous assister pour trouver le bug: les outils type valgrind (et autre memory sanitizers) qui peuvent détecter que l'on lit une donnée non initialisée, et les outils d'analyse statique de code (à commencer par "clang -wall") qui vont émettre un warning comme quoi un chemin du code consomme une donnée non initialisée. C'est juste énorme.
Si par malheur on initialise à une valeur bidon par défaut, aucun outil ne pourra plus nous assister -- ou pourquoi je pense que cette vieille pratique de programmation défensive est aujourd'hui une mauvaise pratique grâce à notre écosystème qui progresse, mais qu'elle (la pratique) neutralise.

Bien évidemment, en retardant la définition, là c'est le compilateur qui ne se gênera pas de nous signaler que l'on écrit de grosses bêtises, ou que l'on refactore un peu trop vite. Et c'est ce qu'il faut préférer!

[emmesse]

merci pour vos contributions
et ce livre "Programming: Principles and Practice Using C++, 2nd edition"?

[delannoy]

...

Je ne sais pas où vous avez trouvé ce code qui n'est pas celui qui figure dans l'ouvrage, que je reproduis ci-dessous :

Code :

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

1
2
3
4
5
6
7
8
9
10
#include <iostream>
using namespace std ;
int main()
{
    int nombre, carre ;
    cout << "donnez un nombre : " ;   /* pas de changement de ligne après écriture */
    cin >> nombre ;
    carre = nombre * nombre ;
    cout << nombre << " a pour carre : " << carre ;
}

Quant à l'initialisation de la variable carre, je vous renvoie au commentaire de Mr Luc Hermite.
Je ne vois pas en quoi l'absence de endl nuit ici au code.
De surcroît, je vous rappelle que nous avons ici affaire à un ouvrage d'initialisation à la programmation qui compare les différentes façons d'exprimer une notion dans différents langages. Ce serait plutôt mieux de lire le bouquin plutôt que de se contenter de chercher à tout prix à trouver des anomalies. Pendant qu'on y est, je vous souffle votre prochaine critique : il serait mieux d'ajouter un return 0 à la fin du main (ou, peut-être un return -1, voire return -9999 puisque le programme ne vous plaît pas...)

Pour info, l'annexe C++11/C++14/C++17 de Programmmer en langage C++ fait 50 pages et pas 10 !

Toujours pour info, je signale aux lecteurs de ce forum que vous avez publié le même jour (21/2/2018) trois critiques virulentes de mes ouvrages (une ici et deux sur Amazon). J'ai du mal à croire que ce soit un hasard, d'autant plus que ce sont les deux seules que vous ayez réalisées concernant des livres chez Amazon... Par ailleurs, pourriez nous expliquer pourquoi votre nom figure dans la traduction 2010 de "Programming principles and practice using C++" de 2010 et plus dans celle de 2012. Auriez-vous du mal à supporter que certains (mauvais selon vous) ouvrages soient populaires (juste avant vos critiques, l'ouvrage était "meilleure vente C++" depuis pas mal de temps). Pour info, voici les deux liens correspondants aux ouvrages évoqués :
https://www.amazon.fr/Programmation-...ct_top?ie=UTF8
https://www.amazon.fr/Programmation-.../dp/2744077186

Je n'ose ajouter cordialement

[JolyLoic]

- J'ai indiqué dans le message où je l'ai trouvé (il suffit de cliquer sur le mot "là" dans la phrase "code consultable là"). Et je ne cherche pas à tout prix des problèmes, c'est littéralement le premier exemple disponible en téléchargement.

- Pour l'initialisation, avez-vous bien lu le message de Luc ?

- Non, je ne compte rien dire sur le return, c'est du code correct, et c'est un détail stylistique de second ordre, contrairement aux autres remarques que j'ai faites.

- L'absence du endl n'est pas le plus grave, j'en parle en dernier. C'est juste que quand on lance le programme, la sortie n'est pas lisible. Et que les version "équivalentes" Java et C# du code ont un saut de ligne.

- J'ai en effet commencer à publier une critique ici, suite à la question de ce post. Puis je me suis demandé pourquoi ce livre était encore régulièrement cité, depuis le temps qu'il est régulièrement décrié. Je suis donc allé voir sur Amazon où il n'y avait pas une seule critique écrite par quelqu'un qui ne soit pas débutant dans le langage. J'ai donc décidé d'en écrire. Voilà, pas de grand mystères, d'agenda caché ni de conspiration sur la simultanéité des critiques.

- Le fait que mon nom soit sur Amazon, dans une édition de la traduction du livre et pas dans l'autre, je n'en sais rien (et je m'en moque un peu en fait). Je ne sais pas trop pour quelle raison vous vous focalisez là dessus ? Dans un cas, ils ont nommé les traductrices, dans l'autre, Michel Michaud et moi qui avons effectué une relecture technique de la traduction. Je ne suis pas au courant de différences entre les deux en terme de contenu, et mon nom est en quatrième de couverture des deux. Et pour info, le but de ma démarche n'est pas de "vendre le mien au dépend du votre". Déjà, ce n'est pas mon style, mais ça vous n'êtes pas obligé de me croire sur parole. Peut-être comprendrez vous mieux l'argument que ce livre n'est plus vendu depuis plusieurs années, et que la version français a globalement été un flop, le public français préférant la version US ? Donc que je n'ai aucun intérêt dans la vente de cette traduction ? En outre, et même quand je gagnais quelques centimes par exemplaire, j'ai toujours recommandé plutôt la version US à ceux que l'anglais ne gêne pas trop, elle est plus complète, et a bénéficié d'une seconde édition. Voilà, j'ai répondu à l'attaque personnelle. Pourrait-on désormais se concentrer sur le contenu technique des livre, plutôt ?

[ParseCoder]

Après vérification, Loïc a raison le code sur le site d'Eyrolles est bien:

carre = 2 * expression

Le gag!

[mintho carmo]

Pour les 2 versions du livre PPPC++ sur Amazon, on en avait déjà parlé il y a longtemps : la version de 2012 est une ré-impression, il n'y a aucun changement par rapport la version de 2010. Et Loic est bien cité sur la quatrième de couverture dans les 2 versions. C'est un "bug" d'Amazon.

Pour "numéro 1 des ventes", c'est un critère un peu bidon. Amazon ne fait pas la distinction entre les différentes éditions et calcul le total des ventes. Du coup, un livre qui est plus ancien sera plus haut dans le classement. Même si la dernière édition est peu vendue.

Et sinon, il y a beaucoup plus de 3 discussions qui critiquent ces livres. Et sur pleins de forums. C'est presqu'un running gag quand quelqu'un achète ce livre, ca fait bien rire les gens.

[mintho carmo]

Un moment donné, il ne faut pas être surpris par les critiques. A ce niveau, c'est du foutage de gueule envers ceux qui achètent ce type de livres.

https://www.eyrolles.com/Chapitres/9...2212676631.pdf (la dernière édition, qui date de mai 2018...)

Le premier code donné :

Code :

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

1
2
3
4
5
#include <iostream>
using namespace std ;
main() // en-tête
{ ..... // corps du programme
}

Ce n'est pas du C++ valide ! Les compilateurs signalent qu'il y a un problème. Par exemple GCC :

Code :

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

1
2
3
main.cpp:3:6: warning: ISO C++ forbids declaration of 'main' with no type [-Wpedantic]
 main() // en-tête
      ^

Et les exos sont du même ordre, avec pleins de codes incorrects et des mauvaises pratiques. (Et ne dites surtout pas que tant que ça compile, c'est pas grave d'avoir des warnings).

Ca fait combien de temps que tu n'as pas mis a jour tes connaissances en C++ ? Voire taper une ligne de code en C++ ?
Le but est juste de vendre des livres en faisant le moins d'effort possible ?

En tant que dev C++ pro, je trouve lamentable d'enseigner ce type de code. Et d'abuser du manque de recul des lecteurs pour leur vendre ce genre de livre.

[JolyLoic]

En effet, ça pique les yeux... Et une rapide lecture rélève aussi :

Il existe trois types entiers : short int (ou short), int et long int (ou long).

Et long long ?

Les opérateurs logiques && (et), || (ou) et (non) acceptent n’importe quel opérande numérique
(entier ou flottant) ou pointeur, en considérant que tout opérande de valeur non nulle
correspond à « faux »

Alors, déjà, il manque le "!" pour l'opérateur "non"... Mais surtout, c'est "vrai". Une valeur non nulle est "vraie"...

En outre, je trouve les rappels très succincts. Pourquoi pas, ce livre n'étant pas autonome, et étant clairement destiné à accompagner un autre ouvrage. Mais dans ce cas, n'aurait-il pas mieux valu ne pas avoir de rappels du tout, et se concentrer sur les exercices et profiter de la place libérée pour donner plus de détails, en mettant en place une vraie démarche d'apprentissage par l'exemple.

Quant au contenu des exercices, je trouve qu'ils se focalisent beaucoup sur des détails du langage et ressemblent plus à des quiz d'entretiens d'embauche qu'à du vrai code réaliste (et qu'ils ne donnent pas très envie d'apprendre la langage, car ils lui donnent une image assez sombre). Je serais curieux de voir ce que ça donne dans des chapitres plus avancés où plus d'outils sont disponibles.