Version imprimable
salut,
au sein de mon entreprise je doit former une personne au C++. Elle n'a aucune expérience ni aucune formation en programation. Généralement après que j'ai dit ça tout le monde fait cette tête 8O. Je suis bien conscient que c'est un challenge et pour lui et pour moi.
voilà mes questions:
Est-ce quelqu'un à déjà fait ce genre d'expérience ?
Quels conseils auriez vous a donner ?
Quel(s) bouquin(s) avez utilisé(s) et/ou apprécier lors de votre formations ?
Bonjour,
Juste pour répondre pour le bouquin : tu peux t'appuyer sur Le Langage C++ de Bjarne Stroustrup, et aussi le livre Programmation en C++ ou quelque chose du genre, par Claude Delannoy. Ce sont 2 bouquins que je trouve très bien faits. A cela tu ajoutes quelques petits documents par-ci par-là et niveau support en lecture ca devrait aller.
La première réponse donnée est une bonne réponse de bouquin de référence. Pas facile de commencer avec -- en VF, viser la 3ed révisée techniquement par Michel Michaud.
La seconde réponse est une mauvaise réponse -- cf les archives de fclc++ pour les critiques récurrentes.
La référence est Accelerated C++, par Koenig et Moo, chez Addisson Wesley, non traduit à ce jour. L'approche peut paraitre novatrice quand on croit que l'on doive enseigner un C++ historique -- en passant par la case C. Un gros intérêt, p.ex., est que le gars que tu vas avoir formé n'aura pas les réflexes de croire savoir manipuler la mémoire pour au final intoduire des bugs qui seront corrigés au dernier moment par des pompiers. L'apprentssage est focalisé sur des aspects de plus haut niveau. L'inconvénient, tu ne pourras peut-être pas le mettre tout de suite en maintenance de code C/C++ (le qualificatif "C/" n'est pas un compliment ici), ou sur des bibliothèques critiques bas-niveau. (Je ne pense pas non plus qu'il faille mettre un débutant en maintenance, pour le plus grand malheur de ceux qui ne le sont pas)
Autre bouquin qui peut t'intéresser, celui de Francis Glassborough, traduit chez Micro-application sous le titre "je me lance" -- la traduction semble avoir quelques défauts comme toute traduction. Pourquoi cela va t'intéresser ? Le profil du cobaye. Personne non informaticienne d'age mûr qui sait tout juste allumer son ordi et lancer un navigateur. Stéréotypes, stéréotypes. En attendant, il semblerait que l'expérience ait été un succès. Petit incovénient, cela n'aborde pas les objets, ne parlons même pas de la généricité. Le bouquin ne présente pas non plus le C++ selon l'approche historique.
Enfin, tu as des profs et autres formateurs qui fréquentent fclc++. Ce genre de questions ont parfois été abordées.
Merci pour vos réponses.
pour le soustrup et le Delannoy évidement je les connais et les ai lus. Mon avis perso est que effectivement Delannoy se permet des entorses par rapport au langage. Mais il est très pédagogue. Pour le Stroustrup, je suis assez d'accord avec Luc, c'est certainement le meilleurs bouquin de référence, mais n'est pas adapté à un apprentissage en partant de rien.
Pour le Accelered C++ je ne connais pas, je vais essayer de le trouver.
Par contre, Luc, peux-tu expliquer ce que tu entends par C++ historique ?
Pour le je me lance je comprend pas bien de quoi parle ce bouquin ? (pas de C++, pas de généricité,...). Il raconte juste comment quelqu'un a appris à développer ?
Juste pour préciser la personne à formé est un testeur expérimenté. Il connait donc bien les produits leur mode de fonctionnement ainsi que tout la partie fonctionnelle .
Pour le mode pompier, les corrections, etc... Notre culture d'entreprise fait qu'ici plus qu'ailleurs on fonctionne comme ça. Notre crédo est qu'il faut mieux arriver avant tous nos concurent avec un produit buggé, plutot qu'arriver après. Et vaut mieux corriger rappidement un bug quit à faire de regression, car comme cela le client pense qu'on s'occupe de lui même si on est moyennement compétent.
[Mode troll]
Notre crédo est qu'il faut mieux arriver avant tous nos concurent avec un produit buggé, plutot qu'arriver après.
Tu travailles chez Microsoft ? :roll:
[/mode troll]
Sinon, moi je commencerais par pas mal de théorie sur la programmation : langage interprété, langage compilé, notion de fonctions et de variables avec l'analogie avec les maths.
Après un p'tit HelloWorld ça fait toujours plaisir :wink: , puis après le tralala sur l'allocation mémoire, la POO, etc...
En tout cas bon courage :wink:
ça peut être une très bonne expérience pour lui, mais pour toi aussi !
non je ne travaille pas chez Microsoft, mais effectivement c'est une analogie que l'on fait souvent et effectivement dans notre branche nous somme leader mondial de l'univers (enfin c'est ce que dit la direction).
Cette effectivement un vrai challenge pour moi !
On peut savoir c'est quoi comme branche?Citation:
Envoyé par BigNic
J'entends ce que ceci me semble sous-entendre: :roll:Citation:
Envoyé par BigNic
A savoir, la présentation de détails qui arrivent généralement trop tôt dans l'apprentissage. Soit parce que c'est comme cela que l'on nous l'a appris (et donc on reproduit les schémas, etc, etc), soit parce que l'on est persuadés que le bout de sous-ensemble C du C++ doit être présenté d'abord parce que au fond le C++ à été "dérivé" du C.Citation:
Envoyé par Luffy Duck
C'est perdre le débutant dans des détails qu'il n'a pas besoin de connaitre au début de son apprentissage. Quel intérêt d'apprendre la syntaxe des spécificateurs de format de printf/scanf, et des notions de pointeurs/adresse dès la seconde leçon (parce que le Hello World doit demander notre nom) en C++ ? Ou plus généralement, pourquoi les tableaux dynamiques gérés à la main via des pointeurs quand on dispose d'abstractions qui encapsulent une bonne partie de la gestion de la mémoire ? Lorsque j'apprenais l'Ada, je n'avais aucun problème à manipuler des tableaux sans même connaitre la syntaxe des opérations de gestion manuelle de la mémoire. Pourquoi le débutant en C++ devrait d'abord commencer à manipuler des tableaux statiques ou dynamiques plutôt que des vecteurs ?
Perso, je pense que l'on peut retarder l'introduction de la gestion dynamique de la mémoire jusqu'au chapitre sur le polymorphisme.
Non, non. C'est bien un bouquin d'apprentissage du C++. C'est juste qu'il est co-écrit entre un formateur et son coba^Wélève qui ne connaissait vraiment pas grand chose à l'"informatique" au moment où la formation avait démarré. Tentes une recherche sur ce titre, on en eut discuté ici sous au moins deux threads.Citation:
Envoyé par BicNic
Il a aussi l'approche non historique : pas de passage par la case C, utilisation intensive des abstractions de la bibliothèque standard (au lieu de commencer par montrer le b-à-ba des mécanismes qui servent à l'implémenter). Et je rajouterai même : pas une présentation du C++ comme une série de règles syntaxiques.
<première disgression>
C'est un point que je regrette dans divers documents. J'ai parfois l'impression qu'il s'agit d'un étalage de règles syntaxique sans précisions sur les conditions d'applicabilité. C'est très bien pour du document de référence. Pour du document censé former des gens qui devront rapidement être productifs, je n'aime pas trop.
Je pense par exemple aux surcharges des constructeur de recopie et opérateur d'affectation qui sont rarement les bienvenus dans les hiérarchies polymorphes -- à cause de la dualité sémantique de valeur (à laquelle ces opérations sont étroitement liées (je simplifie, il est tard)) <-> sémantique de référence/d'entités (typique des hiérarchies polymorphes).
Combien de fois j'ai vu des gens (et moi le premier il y a quelques temps maintenant) s'obtiner à toujours définir en public ces deux opérations de recopie, et s'entendre ensuite "ah ah. Le C++ est tout pourri, pour copier des hiérarchies, il faut des clone()". Mais a-t-on véritablement besoin de toujours dupliquer ces objets entités, qui par nature sont tous différents les uns des autres, combien même ils auraient le même état...?
J'ai bien aimé l'approche de AC++, qui, de ce que j'ai survolé, n'explicite pas ce qu'il faut ou ne pas faire, mais montre des designs types pour les classes de valeur et les classes d'entité. A contrario de : §x les objets ; §x.n les contructeurs ; §x.n.t ctr de recopie ; sous-paragraphe l'opérateur d'affectation (quand il n'y a pas un chapitre entier sur les opérateurs surchargeables) ; §x+1 l'héritage ; §x+1.n' la surcharge ; §x+1.m' le polymorphisme (sous-entendu d'inclusion) ; ...
Tout ça pour dire que le C++ ne se résume pas à une syntaxe, et qu'il y a un certain nombre de règles de cuisine simplificatrices qui permettent de l'utiliser au début dans de bonnes conditions. Au fur et à mesure, on commence à voir les raisons de ces règles, ainsi que leurs exceptions. Ce petit avis personnel pour dire que j'aurais tendance à glisser subreptissement les termes "valeur" et "entité" (quitte à donner des références pour ensuite approfondir) et signaler que "les premières classes se manipulent généralement de telle façon (chapitre) et les secondes de telle autre (chapitres) -- et oui, on peut imaginer des hybrides <fermer la parenthèse, suite dans la formation avancée>".
<seconde disgression>
Des notions de conception objet seront également importantes. Je pense en particulier au LSP. Ne serait-ce que pour sensibiliser la personne à ne pas dériver ListeTriée de Liste.
PS à méditer: Un contenu technique de qualité (technique) parfois désirable, enseigné par un excellent pédagogue, est-ce une si bonne chose ?
Sur ce. ZZZzzzzz.
pour Jean-Marc: la finance.
Pour Luc:
tout ça semble plein de sagesse, la question est de savoir si j'ai le niveau pour le faire.
En tout cas effectivement la séparation entre C et C++ semble ne pas être la même selon les personnes. Dans ma boite la population est assez disparate, mais les anciens sont d'ancien développeurs C qui font maintenant du C++. Donc pour eux il faut absolument passer par C avant C++. Mais c'est soutout parceque pour euxCe n'est pas du C++. Pour eux le C++ commence toujours pas des mot clés comme class, template, virtual etc... Ils confondent paradigme et langage, et ne voit le C++ que à travers les apports qu'il offre par rapport au C. Mais d'autre personne les plus "intelligentes" ou les plus jeunes comprenne bien qu'apprendre le C n'est pas indispensable pour apprendre le C++.Code:for(int v_i;v_i < max;v_i++)
En tous cas merci de vos conseils à tous
quelq'un à une opinion sur le C++ par la pratique de steve oalline aux éditions O'Reilly ?
http://www.accu.org/cgi-bin/accu/rvo...&file=p003502aCitation:
Envoyé par BigNic
Hum. En voulant aller vite et parler d'autres choses, l'idée principale que je voulais faire passer s'est perdue en chemin..Citation:
Envoyé par BigNic
Ce n'est pas une question de niveau. C'est une question qu'il y a des ordres d'apprentissage qui sont vraiment mal venus. En particulier parler trop tôt de la gestion manuelle de la mémoire.
Je qualifie cette approche d'historique et de tirant vers le C dans la mesure où ce langage impose pratiquement de comprendre comment fonctionne la mémoire dès les premières leçons. Ce n'est plus une nécessité en C++. On peut d'abord se concentrer sur des aspects plus haut niveau, ce qui se traduit par le fait que l'on peut être productifs bien plus vite, tout en étant une source de bugs moindre.
Aujourd'hui, les deux bouquins d'apprentissage qui se démarquent le plus de cette approche "historique" sont AC++ et "Je me lance".
Ce n'est pas une question de niveau. C'est une question de faire les choses dans un ordre qui soit plus efficace sur le plan pédagogique.
Dans ma prose précédente, il y a des disgressions propres à ce que l'"enseignement du C++" m'évoque aujourd'hui. Des idées auxquelles je ne peux m'empécher de penser.
Dernier conseil qui peut parraitre trivial et inutile tellement au fond il est évident. Je trouve qu'il est plus intéressant d'utiliser des exemples avec lesquels l'élève sera famillier. Tu dis qu'il a une forte expérience dans les tests, donc probablement par rapport à votre métier (la finance), essaies de trouver des exemples, simplifiés et didactiques, propres au code sur lequel tu travailles ou sur lequel qu'il serait amené à travailler -- extrait de code en adéquation avec la leçon du moment évidemment.
(Préparer un cours/une formation, c'est long.)