Bonjour à tous,

En parcourant le forum c++, je me suis aperçu qu'il a été dit plusieurs fois que le cours de ce site est mauvais pour apprendre le langage. J'aimerai donc savoir en quoi il est mauvais (le fait qu'il soit écrit pour le C++ de 2003 peut être?), et si vous pouviez me donner quelques exemples concrets de ce qu'il ne faut pas faire qui a été dit dans ce cours.

Merci d'avance pour vos réponses.

Lu'!

Tercalen a écrit:

J'aimerai donc savoir en quoi il est mauvais (le fait qu'il soit écrit pour le C++ de 2003 peut être?)

C'est un point (encore que je le situerai à cheval sur 98 et 03), mais ce n'est pas le seul et surtout, ce n'est pas le plus problématique. Les vrais (principaux) problèmes sont l'absence totale d'enseignement des bonnes pratiques de conception, l'utilisation de la gestion manuelle des ressources, l'introduction bien trop tardive de la bibliothèque standard et des exceptions.

Plus de lecture ici pour mon avis.

Tercalen a écrit:

et si vous pouviez me donner quelques exemples concrets de ce qu'il ne faut pas faire qui a été dit dans ce cours.

Copier des personnages, les affecter, manipuler des ressources manuellement avec des new et des delete, etc.

-
Edité par Ksass`Peuk 1 juin 2015 à 13:12:00

Merci pour ta réponse rapide,

Ksass`Peuk a écrit:

manipuler des ressources manuellement avec des new et des delete

Je ne suis pas sûr d'avoir bien compris, est ce que c'est "mal" d'utiliser les new et delete pour gérer des objets, ou est ce que c'est mal fait dans le cours?

Enfin, est ce qu'il existe des cours (en français ou anglais) traitant bien le langage et expliquant les bonnes pratiques?

Tercalen a écrit:

Ksass`Peuk a écrit:

manipuler des ressources manuellement avec des new et des delete

Je ne suis pas sûr d'avoir bien compris, (1) est ce que c'est "mal" d'utiliser les new et delete pour gérer des objets, ou (2) est ce que c'est mal fait dans le cours?

Les deux, mon capitaine.

(1) C++ est un langage à exceptions, faire ce genre de chose manuellement de manière sure, c'est la croix et la bannière. C'est pourquoi on utilise des pointeurs intelligents, les conteneurs de la SL, etc. Pour ne pas le faire nous même. Le seul cas où l'on aura besoin de faire ça manuellement est lorsque l'on implémentera les éléments sus-nommé pour un besoin spécifique, et ce n'est clairement pas un truc que l'on fait quand on débute.

(2) Par exemple :

listeVehicules.push_back(new Voiture(15000, 5));
listeVehicules.push_back(new Voiture(12000, 3));
listeVehicules.push_back(new Moto(2000, 212.5));

c'est complètement buggué. A chaque push_back, s'il échoue, l'allocation passée en paramètre est perdue : fuite de mémoire.

Tercalen a écrit:

Enfin, est ce qu'il existe des cours (en français ou anglais) traitant bien le langage et expliquant les bonnes pratiques?

Le cours en cours d'écriture de @gbdivers.

Le C++ Primer dans sa dernière édition.

Du coup, comment faire pour que ce code soit propre? avec des exceptions?

listeVehicules.push_back(new Voiture(15000, 5));
listeVehicules.push_back(new Voiture(12000, 3));
listeVehicules.push_back(new Moto(2000, 212.5));

(je suis en DUT info, et c'est exactement le genre de chose qu'on nous enseigne...)

On utilise des pointeurs intelligents :

using ptr_vehicule = std::unique_ptr<Vehicule>;

//...

std::vector<ptr_vehicule> listeVehicule;


listeVehicule.push_back(std::make_unique<Voiture>(15000, 5));

//ou encore :
listeVehicule.emplace_back(12000, 3);

//ou encore :
ptr_vehciule moto = std::make_unique<Moto>(2000, 212.5);
listeVehicule.push_back(std::move(moto));

Dans les trois cas, si le push_back échoue, rien n'est perdu.

D'accord, merci beaucoup pour tes réponses, je sais maintenant que je peux oublier la moitié de ce que je pensait savoir en c++... Je vais me mettre au cours de gbdivers en espérant perdre mes mauvaises habitudes

Le truc c'est de ne pas compter sur un DUT (ou une école d'ingé) pour avoir un bon niveau en programmation. En général on va t'enseigner des tas de trucs obsolètes donc c'est important de faire des projets perso et de suivre l'évolution et les bonnes pratiques des langages.

Tercalen a écrit:

Du coup, comment faire pour que ce code soit propre? avec des exceptions?

listeVehicules.push_back(new Voiture(15000, 5));
listeVehicules.push_back(new Voiture(12000, 3));
listeVehicules.push_back(new Moto(2000, 212.5));

(je suis en DUT info, et c'est exactement le genre de chose qu'on nous enseigne...)

Parce que les enseignants sont des dinosaures qui oublient de se mettre à jour

Salut,

De plus, beaucoup de cours ont un handicap majeur : sous prétexte d'apprendre un langage, on laisse le conceptuel (la conception) "pour quelqu'un d'autre", et cela se ressent énormément dans les exemples donnés.

Du coup, selon l'assiduité que tu apportes aux différents cours, tu deviens soit un très bon "pisseur de code", totalement incapable de concevoir la moindre chose de correcte soit un très bon concepteur, incapable d'écrire ou de comprendre la moindre ligne de code (bon, d'accord, je caricature un tout petit peu... mais à peine ).

Or, un bon cours devrait mettre ces deux domaines en relation, car c'est ce que l'on fait à longueur de journée quand on est un professionnel du développement : concevoir la manière d'indiquer à "quelque chose d'aussi bête qu'un ordinateur" ce que l'on a compris de la manière dont une personne imagine ce dont elle a besoin et traduire cette conception en ligne de code.

Vouloir faire l'un sans l'autre, cela revient à faire du vélo sur une seule roue : c'est tout aussi casse-gueule, et parfois bien plus dangereux

C'est d'autant plus bête qu'il n'y a finalement que six principes (en réalité: une loi et cinq principes )qu'il faut prendre le temps de comprendre et de maitriser pour être en mesure de les appliquer correctement : la loi de Déméter et les principes à l'origine de l'acronyme SOLID (SRP, OCP,LSP et DIP... on en a déjà beaucoup parlé sur le forum ).

<AUTOPROMO mode = "on">Mais, si tu veux avoir un guide de "bonnes pratiques" à appliquer, je ne saurais trop te conseiller de lire mon livre (lien en signature)<AUTOPROMO mode = "off">

Merci koala01 pour les principes à suivre, et pour ton livre, je vais y réfléchir

Pour le livre, ne réfléchis pas, achète-le, il est excellent.

markand a écrit:

Tercalen a écrit:

Du coup, comment faire pour que ce code soit propre? avec des exceptions?

listeVehicules.push_back(new Voiture(15000, 5));
listeVehicules.push_back(new Voiture(12000, 3));
listeVehicules.push_back(new Moto(2000, 212.5));

(je suis en DUT info, et c'est exactement le genre de chose qu'on nous enseigne...)

Parce que les enseignants sont des dinosaures qui oublient de se mettre à jour

Jmgr a écrit:

Le truc c'est de ne pas compter sur un DUT (ou une école d'ingé) pour avoir un bon niveau en programmation. En général on va t'enseigner des tas de trucs obsolètes donc c'est important de faire des projets perso et de suivre l'évolution et les bonnes pratiques des langages.

Je suis en DUT info, et on nous dis très précisément de ne pas le faire. On nous prépare aussi aux design pattern (en seconde année seulement, à mon grand regret) etc. Après, je suis d'accord, l'étudiant est en charge de sa propre formation (dans la même mesure que l'étudiant a le choix de bosser sérieusement ses TP ou pas). Mais à partir du moment où tu comprends que le C++ n'est pas un langage qui est doté d'un garbage collector, tu sais que faire un pushback avec une allocation de mémoire dynamique, c'est pas forcément la meilleure idée.
J'trouve ça un peu dommage de directement dire "la formation dans les DUT est nulle".

-
Edité par Helheim 3 juin 2015 à 0:17:05

@Heheim : Il a dit "en général" et il a bien raison ! Le plupart des gens qui viennent de DUT font du c++ paléolithique et nous demandent de les aider sur des exercices datant du crétacé !

Tu es en quelque sorte l'exception qui confirme la règle et c'est tant mieux pour toi !

On pourrait avoir le nom de ton école ? Pour qu'on puisse peut être la conseiller.

Je suis moi même en DUT Info et j'ai eu de la chance d'avoir en Java un très bon professeur, très orienté sur les bonnes pratiques et la conception. Parce que ce qu'on a fait en C++, c'est juste du C + cout. Tout ce que j'ai appris du bon C++, c'est à dire du C++ moderne avec les bonnes pratiques, je le dois à de très bons livres et pédagogues sur divers forums, mais certainement pas à ce que j'ai vu à l'IUT.

zeFresk a écrit:

@Heheim : Il a dit "en général" et il a bien raison ! Le plupart des gens qui viennent de DUT font du c++ paléolithique et nous demandent de les aider sur des exercices datant du crétacé !

Tu es en quelque sorte l'exception qui confirme la règle et c'est tant mieux pour toi !

On pourrait avoir le nom de ton école ? Pour qu'on puisse peut être la conseiller.

DUT aix-en-provence. Après j'suis très curieux et investi, alors ptet que ça change quelque chose.

Helheim a écrit:

zeFresk a écrit:

@Heheim : Il a dit "en général" et il a bien raison ! Le plupart des gens qui viennent de DUT font du c++ paléolithique et nous demandent de les aider sur des exercices datant du crétacé !

Tu es en quelque sorte l'exception qui confirme la règle et c'est tant mieux pour toi !

On pourrait avoir le nom de ton école ? Pour qu'on puisse peut être la conseiller.

DUT aix-en-provence. Après j'suis très curieux et investi, alors ptet que ça change quelque chose.

Je ne pense pas que le problème vienne de mon travail en cours ni de mon investissement, mais le fait est que les cours de C++ se résument à faire du C avec des classes et du "cout".
Après, je n'ai pas dit non plus que la formation de DUT est nulle, les cours sont très intéressants et incitent a travailler par soi-même et je trouve ça très.

markand a écrit:

Tercalen a écrit:

(je suis en DUT info, et c'est exactement le genre de chose qu'on nous enseigne...)

Parce que les enseignants sont des dinosaures qui oublient de se mettre à jour

Comme si on n'avait que ça à faire !

Voir quand même aussi que, chez les professionnels de la profession, c'est pas forcément brillant côté mise à niveau des connaissances et abandon des mauvaises pratiques.

Alors que eux, ils sont censés connaitre parfaitement pratiquer tous les jours ce que les autres enseignent par hasard et/ou corvée alimentaire, en y travaillant à la chandelle la veille au soir parce que c'est très loin de leurs vraies occupations sérieuses.

-
Edité par michelbillaud 4 juin 2015 à 13:23:32

michelbillaud a écrit:

Voir quand même aussi que, chez les professionnels de la profession, c'est pas forcément brillant côté mis à jour des connaissances et abandon des mauvaises pratiques.

Tellement +1.

Mais tellement +1.

michelbillaud a écrit:

[...]

C'est bien vrai, mais je trouve que c'est un vrai problème. Les enseignants devraient être les vrais spécialistes de leur domaine, puisque c'est eux qui vont former les futurs professionnels. Enfin, on retombe dans l'éternel débat entre l'enseignement et la recherche, comment évaluer l'un et l'autre, comment éviter que la partie recherche (ou enseignement) prenne trop de temps par rapport à l'autre, etc.

michelbillaud a écrit:

Voir quand même aussi que, chez les professionnels de la profession, c'est pas forcément brillant côté mise à niveau des connaissances et abandon des mauvaises pratiques.

Forcément, le boulot ne conssiste pas à faire propre et moderne, mais mettre en œuvre une solution à moindre coût.
En clair: c'est moche,  ca repond au besoin ==> on prend !

Voila comment on fait des usines à gaz.....

michelbillaud a écrit:

Voir quand même aussi que, chez les professionnels de la profession, c'est pas forcément brillant côté mise à niveau des connaissances et abandon des mauvaises pratiques.

Tout à fait d'accord, certains dinosaures dans les développeurs refusent de se remettre en question et posent énormément de problème.

Mais, bien au delà de cette "poignée de dinosaures récalcitrants", il y a tous les "jeunes fraîchement débarqués" pour lesquels il serait tellement plus simple de leur avoir directement appris les bonnes pratiques actuelles, au lieu de les avoir habitués à des choses qui ne sont plus faites ni à faire depuis quinze ans...

Et c'est là que l'enseignement a une part de responsabilité

Alors que eux, ils sont censés connaitre parfaitement pratiquer tous les jours ce que les autres enseignent par hasard et/ou corvée alimentaire, en y travaillant à la chandelle la veille au soir parce que c'est très loin de leurs vraies occupations sérieuses.

-
Edité par michelbillaud il y a 6 minutes

Nous sommes tous pleinement conscient du fait que l'enseignement fait office de "parent pauvre dans de nombreux pays européens, et que les enseignants font souvent "du mieux qu'ils peuvent" avec des moyens dérisoires.

Cependant, force est de constater que ce "mieux qu'il peuvent" est beaucoup trop irrégulier :

En effet, comment peut-on expliquer que certains profs arrivent à faire une veille technologique suffisante pour faire évoluer leur cours au lieu de se contenter de resservir l'apprentissage de C++ exactement "tel qu'on le leur a présenté il y a vingt ans" et que d'autres n'arrivent décidément pas à le faire?

Bien sur, chaque prof a sa propre situation qui fait que chacun aura ses propres raisons / justifications. Et il ne m'appartient certainement pas de juger de la pertinence de ces raisons.

Mais, voilà, un fait demeure : certains y arrivent.  Dés lors, posons nous la question de savoir ce qu'il manque aux autres pour y arriver... Un minimum de temps et de budget, sans doute.  Mais combien ne veulent simplement pas envisager de faire l'effort ?

Déjà, il faut s'être rendu compte qu'on n'est pas à jour. Ce qui n'est pas si évident que ça, quand tu fais 2h de cours pour débutants par semaine sur un sujet, tu n'as pas vraiment d'occasion de voir que tu es décalée par l'arrivé de nouvelles pratiques que tu ne vois absolument pas passer.  Le cours de l'année dernière marchait bien, on essaie d'améliorer les exos qui ne passaient pas, et puis voila. Sachant que des sujets, t'en as 4 ou 5 pour t'occuper en parallèle.

C'est comme ça qu'on a mis quelques années à s'apercevoir qu'il y avait Fortran 77, et puis Cobol 85 etc. Mais avec un retard qui n'était pas tellement pire que "l'industrie".

(dois-je évoquer Pacbase ?)

Un autre facteur aussi, c'est les vacataires/thésards dont on fait grand usage parce vous êtes trop radins pour payer des impots supplémentaires qui permettraient d'avoir des titulaires (même avec les bas salaires et le gel du point d'indice actuels). Ca peut être un bien si un "temporaire" débarque avec une bonne connaissance bien à jour d'un sujet, et arrive à le faire passer tant auprès des étudiants qu'auprès des collègues avec qui il doit être synchro. Mais si c'est un thésard débordé, il va reproduire le cours standard qu'il a suivi plus ou moins bien 5 ans avant et puis basta. (Sachant que ce cours lui-même....)

-
Edité par michelbillaud 4 juin 2015 à 14:16:13

michelbillaud a écrit:

c'est les vacataires/thésards dont on fait grand usage parce vous êtes trop radins pour payer des impots supplémentaires qui permettraient d'avoir des titulaires (même avec les bas salaires et le gel du point d'indice actuels).

(D'ailleurs, si quelqu'un cherche un vacataire pour du C++ en région parisienne, je connais un gars qui se démerde en C++).

Ksass`Peuk a écrit:

(2) Par exemple :

listeVehicules.push_back(new Voiture(15000, 5));
listeVehicules.push_back(new Voiture(12000, 3));
listeVehicules.push_back(new Moto(2000, 212.5));

c'est complètement buggué. A chaque push_back, s'il échoue, l'allocation passée en paramètre est perdue : fuite de mémoire.

Pourquoi un push_back échouerais ? En général les instructions réussissent systématiquement non ? Je n'ai jamais vu un code planter à cause d'une allocation dynamique.

-
Edité par Anonyme 4 juin 2015 à 19:04:35

AkihikoKayaba a écrit:

Ksass`Peuk a écrit:

(2) Par exemple :

listeVehicules.push_back(new Voiture(15000, 5));
listeVehicules.push_back(new Voiture(12000, 3));
listeVehicules.push_back(new Moto(2000, 212.5));

c'est complètement buggué. A chaque push_back, s'il échoue, l'allocation passée en paramètre est perdue : fuite de mémoire.

Pourquoi un push_back échouerais ? En général les instructions réussissent systématiquement non ? Je n'ai jamais vu un code planter à cause d'une allocation dynamique.

Ben parce que push_back fait aussi une allocation dynamique. Qui te dis que cette allocation ne va pas foirer ?

AkihikoKayaba a écrit:

En général les instructions réussissent systématiquement non ? 

int x = 4 / 0;

AkihikoKayaba a écrit:

 Je n'ai jamais vu un code planter à cause d'une allocation dynamique.

while (1)
{
   voiture.push_back(new Voiture);
}

AkihikoKayaba a écrit:

Pourquoi un push_back échouerais ? En général les instructions réussissent systématiquement non ? Je n'ai jamais vu un code planter à cause d'une allocation dynamique.

C'est bien le problème d'une mauvaise formation : penser que les choses se passent systématiquement bien.

Et personne ne voient jamais les codes planter a cause des allocations dynamiques. C'est bien pour cela que le C++ est aussi safe...

AkihikoKayaba a écrit:

Pourquoi un push_back échouerais ?

La question c'est surtout : qu'est ce qui te dit qu'il n'échouera pas. Si la documentation te dit "ça peut échouer" alors, ça peut échouer. Et la documentation nous dit :

If a reallocation happens, the storage is allocated using the container's allocator, which may throw exceptions on failure (for the default allocator, <tt>bad_alloc</tt> is thrown if the allocation request does not succeed).

AkihikoKayaba a écrit:

En général les instructions réussissent systématiquement non ?

Ben non, pas forcément, loin de là.

AkihikoKayaba a écrit:

Je n'ai jamais vu un code planter à cause d'une allocation dynamique.

Tu n'as donc jamais fait de programmes avec beaucoup d'allocations.

-
Edité par Ksass`Peuk 4 juin 2015 à 19:36:20

Moi je souhaiterais savoir ce que Nebra apporte au cours, à part la mise en page et le style dit "Site Du Zero" ? Parce que a priori lui son truc c'est HTML/CSS/PHP. Quelle est son expérience avec C++ sur des projets qui sont ou ont été en production ? Si la réponse c'est aucune, alors il n'est pas légitime pour coécrire un cours C++, ou alors juste pour la forme.