Discussion :

[Luc Hermitte]

Ce n'est pas un question d'aller trop vite, mais de ne pas les perdre dans des détails qui leur seront inutiles. Pour cela, on va faire en sorte d'aller le bon ordre.
Ce n'est pas une question de leur parler de la STL, mais de la SL au fil des besoins. On veut rentrer le nom d'une personne ? -> std::string. On veut un tableau non statique -> std::vector. C'est un bon début et il n'y a pas besoin de rentrer dans les détails.

std::string a une sémantique de valeur, je ne concèderai pas que c'est moins simple à utiliser que des char*, ou même des tableaux statiques de caractères. Et puis, on veut présenter les tableaux ? "Tiens, je vous montre un truc juste avant : pour accéder au premier caractère d'une chaine ch, on écrit ch[0]". Chapitre d'après, "vous vous souvenez des chaines ? Et bien les tableaux ça y ressemble."

Un gars qui doit concevoir des bibliothèques bas niveau doit maitriser ces détails, c'est un fait. Le gars qui assemble des petits modules pour arriver à un truc un peu plus gros mais dont les résultats devront être vite perceptibles n'a pas besoin de ces détails.

Le Pascal et mieux l'Ada sont des langages royaux sur le plan pédagogique. Et pourtant on ne montre jamais dans ces premiers cours comment on manipule les pointeurs, leur arithmétique, ... A la place, on utilise au maximum leur types dédiés pour les tableaux et les chaines. Est-ce un problème de ne pas savoir comment ça marche en interne ? Non, absolument pas.

Pourquoi le C++ devrait être présenté comme une surcouche du C, ce qu'il n'est plus ?

Raison de plus parce que ce sont des gens inexpérimentés, on devrait leur montrer le côté utilisation avec des exemples pratiques et motivants -> gérer un carnet d'adresse/ bibliothèque/médiathèque personnelle, un jeu du pendu, un jeu de puissance 4 (pour jouer à deux, l'élève sur 30 qui est motivé et en avance pourra s'amuser à faire l'IA)
Algorithmiquement parlant, cela ne manque pas de challenges. Et à aucun moment, on n'a besoin de voir un seul pointeur!!

Pour la convertion chaine <-> nombre, le langage propose déjà des outils. Pour un informaticien, OK on va montrer l'algo. Pour un débutant, il y a d'autres algorithmes tout aussi valables et qui plus est des qui ne supposent pas des connaissances en mathématiques qu'ils risquent d'avoir oublier depuis longtemps.


L'Accelerated C++ suppose des bases en agorithmique, en revanche la démarche de que Francis Glassborrow expose dans son bouquin a semble-t-il été testée avec succès sur de parfaits débutants. Je maintiens mon conseil quant au bien fondé de sa consultation.


Bref, cette approche est au contraire pragmatique. On montre juste ce qui est nécessaire de savoir pour concevoir des programmes simples. Les pointeurs on n'en a guère un besoin crucial avant l'introduction du polymorphisme et de la sémantique de référence. Et peut-etre même qu'ils pourraient être familiers avec les itérateurs au moment de les aborder.

Et si il y a un élève sur les 10 qui pose la question de savoir "comment c'est fabriqué std::string", et bien on aura tout le temps de lui expliquer la chose entre deux cours ou lui dire de patienter jusqu'aux annexes.

PS: je ne casse pour ma part pas du prof. Je sais très précisément à quel point monter un cours de C++ n'est pas un problème facile et évident entre les contraintes de cohérence avec le cursus, le public, ce que l'on voudrait montrer, les heures dont on dispose, le temps dont on dispose pour préparer le cours ou reprendre un truc qui existe, ....
J'estime qu'il y a un réel problème dans l'enseignement du C++ et mes remarques ne sont qu'à vocation d'améliorer le support de quelqu'un ouvert aux critiques.

[Aurelien.Regat-Barrel]

Prendre un public de bachelier et leur parler de STL au troisième cours cela se fait mais "passe mal" avec des étudiants débutants. Il faut bien voir que pour eux, ils ne connaissent que word un mois avant ! Je connais des cours de C++ où en 20 h on a vu tous les concepts du pur C++ normalisé et où effectivement on parle d'héritage et de virtualité au dixième transparents.

STL, template, je suis d'accord c'est compliqué. std::string je trouve ça beaucoup plus simple que les char *, idem std::vector. Pas de gestion manuelle de la mémoire, syntaxe plus lisible et naturelle, etc...
Pour moi héritage / virtualité c'est pas du C++, c'est de l'objet. On peut faire ça en Java ou XXX, c'est kifkif. Appeler ça un cours de C++ je trouve ça très réducteur. On sort de là en croyant que C++ c'est du C avec des classes. C'est ce que j'ai cru un moment. C++ = classes. Ben en fait non, y'a rien de C++ là dedans. Etudier l'héritage et la virtualité en Java ou Python c'est pareil, et même plus simple.
Si on fait un cours pour apprendre C++, on se doit selon moi d'utiliser ses conteneurs standards, normalisés. On saisit alors ce que peut apporter C++ et justifier son choix : sa vaste bibliothèques de TAD tout prêts à l'emploi. Ca c'est spécifique C++, bien plus qu'un code exemple d'héritage qui compile indifférement en C++, Java ou C#.
Je trouve ça gonflé de mettre C++ sur son CV (ce que chaque étudiant fera) sans avoir entendu parler de la STL.

Vous, vous les voyez jamais ces étudiants car ils se plantent dans leur études. Regardez le taux d'échec dans l'ex DEUG ! On est allez trop vite et on n'a pas compris qu'il faut commencer par des choses simples

Beaucoup d'étudiants se plantent car ils se sont trompé de voie aussi. Je suis d'accord qu'il faut enseigner des choses simples, et c'est exactement pour cela que je préconise std::string au lieu de char *.

Je prends acte de votre point de vue qu'apprendre de C est inutile et qu'on perd son temps ! C'est possible par contre je connais des enseignants qui on essayé de commencer par le C++ avec un public 18-20 ans : beaucoup d'échecs et j'en connais des tonnes qui sont revenu en arrière. Je connais aussi beaucoup de cours de C++ si ambitieux qu'à la fin 7 étudiants sur 10 n'ont rien compris ! Il ne faut pas conclure trop vite et je respecte votre point de vue

Attention, je n'ai pas dit qu'apprendre le C est inutile. Apprendre le C pour faire du C++ oui c'est inutile, je pense même que c'est néfaste. Apprendre le langage C pour faire du C pas de problèmes. Apprendre du C/C++ par contre...

Faites aussi attention que "casser du prof" est facile et que je passe moins de temps que beaucoup d'entre vous (les étoilés) à programmer !

Oui, toujours pareil. C'est les plus ouverts d'esprit et les plus pédagogues donc qui discutent et trinquent pour les autres
Personnellement, je pense savoir faire la part des choses. Je dois avoir un ton assez brutal, mais je n'ai aucune rancoeur ou je ne sais quoi
De même que c'est un professeur qui m'a dégouté du C++ & de l'objet, c'en est un autre qui m'a réconcilié et fait aimer ces 2 là. Ce que je reproche à l'enseignement, surtout universitaire, c'est cet espèce de mépris de la programmation, cette tâche presque dégradante, indigne d'un chercheur / diplomé Bac>3 (les pisse-code). C'est un peu exagéré, mais pas tant. On nous enseigne les bases de la programmation, et puis plus rien. Les étudiants, comme par magie, deviennent de bons programmeurs. Je ne pense pas vous apprendre quelque chose en vous disant que pas mal d'étudiants, même à un haut niveau, ne conçoivent pas de savoir quelque chose si on ne leur a pas apprise en cours. Posez une seule question en interro dont la réponse ne figure pas telle quelle dans le cours et c'est un scandale (je casse aussi les étudiants ). C'est passer à côté des études selon moi, où on est censé apprendre à apprendre.

Savoir manipuler les chaînes sous forme de char * permet d'approfondir l'algorithmique : comment transformer une chaîne en un entier par exemple ? L'algo est simple mais les étudiants galèrent pour le trouver

On peut très bien faire travailler sur cet algo avec std::string. Sinon dans ce cas pourquoi ne pas utiliser uniquement les GOTO à la place de for, while, etc... ? Parce que GOTO c'est mal. Ben char * aussi, c'est mal. De même qu'on utilise for, while, do, etc... qui sont des mots clés du langage, je trouve normal d'utiliser std::string, std::vector, std::list qui sont des TAD du langage. Rien n'empêche de se coder un ou 2 TAD en TP comme on coderait for ou while avec des GOTO, mais bon, arrivé à un moment on a compris l'idée. On donne un cours de TAD, on explique qu'ils sont presque tous présents en C++. Je trouve plus utile de coder un TAD qui n'existe pas en C++, comme l'arbre, plutot qu'un type déjà existant.
Utiliser des types tout prêt n'empêche pas de faire de l'algorithmie. Je dirais même au contraire que leur disponibilité permet de se concentrer sur l'aspect algorithmique au lieu de perdre 4 heures à coder sa pile qui va servir à je ne sais quoi. Car coder une pile, c'est plus une prise de tête sur la syntaxe, l'allocation et tout ça que sur l'algorithmie.
Par contre coder sa fonction de conversion std::string -> int au moyen d'une pile, on peut se concentrer sur l'algorithmie et laisser de côté l'aspect syntaxique.
Mon raisonnement est simple : tout le temps qu'on consacre à déboguer un pointeur, on le consacre pas à autre chose. C'est ce que je considère comme du gaspillage. Y'a pas d'algorithmie à pourrir son code de printf("coucou\n"); pour trouver où le char * plante.

1) on commence par les choses avec tous les concepts bien comme il faut
et petit à petit on explique comment ça marche.
2) On commence par les choses simples ( ce que vous appelez usine à gaz), on explique les insufissances et on montre un nouveau concept qui va combler ces insuffisances.

C'est pas ce que j'entends par usine à gaz. Y'a une règle simple, que les élèves devraient recopier 100 fois. Moins on écrit de lignes, et mois y'a de bugs. Alors avant de partir dans un type X, Y et Z qui stockent des pointeurs de tableaux d'indices qui... aller sur google 10 minutes voir si y'aurait pas quelque chose qui existe déjà et comment s'en servir, c'est ce que j'appelle apprendre à apprendre.

[merrheim]

Merci pour vos conseils : apparamment nous sommes en désaccord sur la manière de procéder. Partir du haut ou du bas ? Utiliser ou non dès le début les librairies standards ?
Pour moi un cours doit aborder les points suivants :
- comment on utilise ?
- comment ça marche (en simplifiant bien sûr) ?
Les 2 notions doivent être abordées en parallèle.
J'estime de plus qu'il faut partir du bas pour montrer comment petit à petit le C++ s'est construit et continuera d'évoluer.
Pour les exemples motivants (médiathèques,puissance 4,...) ils sont déjà dans mes exercices et j'ai maintes fois été battu par leur satané puissance 4.
A sortir bientôt dans la même série :
- concepts avancés en C++
- interface graphiques sous QT
Il va ya avoir du sport....

[Aurelien.Regat-Barrel]

Merci pour vos conseils : apparamment nous sommes en désaccord sur la manière de procéder. Partir du haut ou du bas ? Utiliser ou non dès le début les librairies standards ?

Si c'est un cours de C, la bibliothèque (attention au terme librarairie) standard c'est les char * et strlen, strcpy, ...
Si c'est du C++, la biliothèque standard c'est std::string.

Pour moi un cours doit aborder les points suivants :
- comment on utilise ?
- comment ça marche (en simplifiant bien sûr) ?

Comment on utilise -> cours de C ou C++
Comment ça marche -> cours d'algorithmie.
Exemple : le TAD pile : principe en cours, mise ne pratique avec std::stack en TP de C++.

[la drogue c'est mal]

remarque pratique :

est que tu pourrais ajouter des indentations dans ton code. Ca le rendra plus lisible parce que tout aligné à gauche quand on a 3 boucles imbriquées c'est lourd à lire

[merrheim]

Je sais "la drogue" j'essaye d'améliorer la lisibilité du code version après version
dur dur !

[PINGOUIN_GEANT]

je n'ai pas l'impression qu'il y a un index pour trouver un point précis (genre je veux me renseigner sur les templates)

personnellement je préfère les cours écrits sous forme de vrais polycopiés et pas de transparents s'il n'y a pas de support audio derrière (un prof. en quelque sorte)

d'après ce que j'ai lu du thread, en 1° année on commence à programmer en C++ ? je trouve cela dingue

[merrheim]

Pour nous réconcilier il sortira (vers le mois de mai) une nouvelle version du cours (moi je garde la mienne pour faire mes cours !) où les concepts du C++ seront étudiés en introduisant au plus tot les librairies standard : on abordera dans le même chapitre les tableaux et les vecteurs !
Chiche !

[mtopoloff]

Le probleme est bien plus profond !
Ayant fait un cycle universitaire en parallele au travail en entreprise (eh oui, vive les cours du soir à Paris 6), j'ai remarqué le gouffre qui separe les deux.
J'ai appris à programmer tout seul, en faisant des jeux. Puis je me suis amélioré en travaillant avec des gens doués et experimentés.
Mais je pense qu'il est essentiel d'apprendre aux etudiants à quoi va servir leurs connaissances en C++. N'oubliez pas, cher professeur, que demain, vos etudiants devront fabriquer des composants fonctionnels, avec les contraintes de productivité de l'entreprise, loin des theoriques char * et *i++.
Pour cela il faut leur apprendre tres tot l'utilisation des outils professionnels (Visual, Ecclipse, Builder..) avec des projets d'apprentissage realistes (arretez avec vos fonctions foo et les regexp). Ou on leur apprend pas seulement comment coder une fonction en C++ mais aussi comment créer un projet sous Visual Studio (ou un IDE GNU) comment utiliser les outils de debug, de versionning. Et cela ne prendra pas beaucoup de plus de temps mais sera tellement plus utile que d'apprendre par coeur la syntaxe du C/C++ qu'on peut tres facilement retrouver sur Internet, MSDN etc... Il faut, dans le cours d'informatique, leur apprendre à se servir des principaux outils et d'appliquer des methodes de developpement (RAD)....
En gros passer sous forme de reference le cours en C++ et etudier plus en profondeur les methodes et les outils.

[bigboomshakala]

re-moi

j'ai pas pu suivre les débats, jme suis tapé 220 bornes aller-retour.
enfin bref.

en ce qui concerne le plan, pour réconcilier un peu tout le monde je serais d'avis de faire 2 parties :

Partie 1 : Notions de C
Chapitre 1 : kekchoz
...

Partie 2 : Cours de C++
Chapitre 1 : concepts objets, gnagnagna
Chapitre 2 : les différences entre C et C++
...

dans la partie 1 (qui n'a pas a être très longue), on peut parler des instructions que l'on retrouvera dans le C++

Code :

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

1
2
3
for (...) {intructions;}
while (condition) {instructions;}
...

des instructions propres au C

Code :

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

1
2
3
malloc
free
types_basiques * (dont notre ami le char *)

des conventions d'écriture (+ indentation)

Code :

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

1
2
3
4
5
//constantes en majuscule
#define MON_ENTIER 10
//variables en minuscule
int monEntier = 12;
int mon_entier = 27;

ensuite viens la Partie 2 qui nous intéresse, et là pif paf pouf les concepts objets d'abord :

sans code, présenter des diagrammes de classes pour illustrer, prendre un ou deux exemples concrets style une classe CAnimal
- par la même occasion donner les convention d'écriture au fur et à mesure (nom de classe en minuscule avec un "C"+ la lettre suivante en majuscule) - donc faire le diagramme de cette classe, introduire l'héritage (le concept, pas de code dans les chapitres qui introduisent les concepts)
avec le diagramme UML où on retrouve la classe CAnimal et dont dérive CHomme, CChien, CTruie ...

ensuite vient le chapitre qui montre les grosses différences C/C++ (outre que le C++ soit un langage objet)

et passé ce chapitre ne mettre que du code C++!
i.e. std::string, std::vector ..., éventuellement virer les std:: en mettant un using namespace std pour débuter (sans trop expliquer le std::, faire référence au chapitre qui parle des namespace et de la STL, le but au début étant de manipuler. plus tard on dira d'où sorte les aliens 'std::'. on peut se passer de le savoir pour comprendre la prog C++)

bon ben ché pas ske vou en pensé, n'hésitez pas à me trucider. allez-y j'aime ça !!!!

[merrheim]

Il est dommage que le débat tourne à la croisade anti-universitaire (j'ai beaucoup apprécié le "cher professeur"). Je ne pense pas qu'une approche orientée outils soit une bonne solution : les outils changent vite et il vaut mieux je crois commencer par apprendre des notions indépendamment des compilateurs. J'estime que mes apprentissage sont réalistes et je n'ai jamais posé le moindre devoir qui traite de la syntaxe du C++.
J'estime qu'un étudiant qui sort de licence informatique doit connaître ce qu'est un char * et doit connaître la classe string et la STL et doit aussi connaître quelques outils de développement ( je propose dev-cpp et visual C++ dans mes cours). Il doit aussi savoir développer une application C++ comportant une interface graphique. Par contre nous divergeons fortement sur les moyens d'y parvenir !
j'au toujours été un universitaire farouchement opposé à un unique apprentissage théorique. c'est pour cette raison que , même si vous n'aimez pas mon cours, je propose de nombreux exercices aux étudiants certains théoriques pour voir s'ils ont compris les concepts et d'autres très pratiques (comment gérer une DVDthéque) ! C'est aussi pour cette raison que je suis venu ici dans cette jungle !!!
bigboom pose également une bonne question : où mettre l'UML ?
ça aussi c'est une problème pas si évident que ça !
Et un autre problème majeur : où mettre la programmation système ? est-ce inutile ? Comment faire si on n'a pas vu le C (d'où mon approche C puis passer en douceur au C++) ? Peut-on traiter ce sujet en C++ pur ?
L'idéeal serait de traiter à fond le C puis à fond le C++ puis à fond java et a fond l'UML mais là arrive la contrainte du nombre d'heures de cours !
Finalement c'est pas si simple la programmation !
Qui apporte une proposition ?

[Aurelien.Regat-Barrel]

je propose dev-cpp et visual C++ dans mes cours

moi je trouve ça très bien. J'ai touché à rien d'autre que emacs en 5 ans d'études. Beaucoup étudiants qui étaient avec moi ont quitté l'école sans avoir vu ou même savoir ce qu'est Visual C++. Je trouve ça bien que vous y fassiez une initiation. Cela dit je ne suis pas d'accord avec mtopoloff. On ne doit pas former à un RAD particulier. Initier oui. Un TP d'initiation je trouve ça bien, et suffisant.
La programmation système c'est un autre domaine à mon avis. Moi j'ai appris le C en cours de système par le prof de système, et le C++ en cours d'OO par le prof d'OO.

[Luc Hermitte]

Initier aux outlis OK, mais pas former. Je suis d'accord les outils changent et tout le monde n'a pas les mêmes gouts ni les mêmes attentes une fois que l'on doit développer pour de bon.

UML est à voir en parallèle d'un langage OO et d'une méthodologie (UP ou autre) -- car au fond, juste UML seul il n'y a pas de quoi avoir un truc vraiment pertinent.
Il y a moins d'une semaine, le manque de sensibilisation aux méthodes de tests (voir p.ex. les test units) était d'ailleurs souligné sur fclc++.


Notre point d'"accroche" n'est pas ce qui doit être enseigné, mais l'ordre dans lequel procéder.


La programmation système est dans un module à part. Dans mes souvenirs, j'avais eu un mélange de C, Ada et modula (gros projet durant lequel on avait développé un noyau transactionnel). Et justement, en lisant les propos d'Herb Sutter (une toute petite phrase au sujet du langage d'API pour .NET) je m'interroge quant à l'avenir du C dans la programmation système sous .NET.

[bigboomshakala]

NOTE : je suis d'accord avec le fait de faire toucher aux IDE.

perso, après un DESS et une école d'ingé Info, j'ai pas touché à un IDE pour programmer du C++ (c'est fou ça quand même). je n'ai fait que de la ligne de commande et souvent dans un éditeur de texte sans coloration syntaxique (un bloc note sous Unix quoi, c'est caca pour s'y retrouver dans le code et dans les différents fichiers du projet).

ya qu'en DESS que j'ai touché à un IDE, c'était pour faire de l'EIFFEL (et bonjour l'environnement vachement complexe! complet, mais complexe, cf. le lancer de caillou et autres)

aussi je suis complètement d'accord pour faire toucher à VC++ ou autre, mais éventuellement après avoir fait de la ligne de commande histoire d'abord de se concentrer sur les concepts et la syntaxe s'en s'embrouiller en plus avec un IDE.

(fournir un makefile type où ya plus qu'à changer les noms des fichiers à compiler)

NOTE: à un moment ou un autre faut apprendre à faire un makefile (j'ai pas fais gaffe si c'était ou pas dans le cours)

[merrheim]

On peut se poser des questions quant à l'avenir du C.. On a dit ça pendant des années du cobol : il n'est pas mort si vite (excusez moi je pense qu'il est encore vivant) !
On peut voir la programmation système uniquement selon l'axe .net. Cela enterrine donc que microsoft fixe tous les standards de l'informatique. Il y a des gens qui pensent que voir à la fois linux et les standards microsoft est une bonne solution. C'est vrai qu'il s'agit là d'un bon système d'exploitation même si en part de marché il est loin derrière microsoft !
Aujourd'jui on ne peut pas non plus multiplier les langages car il faut étudier je crois le C++ et le java et cela prend du temps.
Je crois encore à la nécessité d'apprendre le C.
Finalement vous m'avez convaincu :
- pour le public bac+1 à BAC+3 j'utiliserais ma méthode
- pour un public plus mature, on peut peut-être apprendre directement le C++ mais je ne suis pas certain qu'ils conprennent si bien que ça car le problème c'est que dans les BAC+4 à BAC+5 le niveau des étudiants baissent lentement mais surement (car le nombre des étudiants augmente !).
Il y aura donc 2 cours de C++ sur mon site avec é approches différentes! Vous aurez 2 fois plus de critiques sur les fautes d'orthographes !
merci à vous !

[merrheim]

Pour le makefile j'ai pas encore décidé ou le placer. c'est pas si facile : les étudiants s'en fouttent un peu lorsqu'ils connaissent un IDE ! Je peux botter en touche en disant que c'est du système... trop facile ...

[bigboomshakala]

à tout casser, tu peux le mettre en annexe (c'est un cours uniquement sur le net à la dispo des étudiants ou c'est un support à un cours+TP?. dans le 2è cas fo obligatoirement leur faire faire un makefile au moins 2 fois - le 2è c'est parce que généralement y zon rien capter la 1ère fois )

par contre faut que ça soit bien détaillé, dire ce qu'il est obligatoire de mettre et à quoi ça sert, et les options qui peuvent être ajouté, fournir un squelette de makefile + des exemples complets concrets pour des projets contenant plusieurs fichiers.

[Aurelien.Regat-Barrel]

Pour moi, le makefile c'est dans la catégorie initiation aux outils. Un TP sur emacs (ou vi pour faire plaisir à Luc :-), un sur VC++ et un sur les makefiles.
Pour la prog système en C, c'est plutot la prog système tout court qui devient moins fréquence. Avec des frameworks comme Qt tu n'as plus trop besoin de passer par les API systèmes en C.
J'ai fait IUT, licence&maitrise, DESS (2 universités différentes). Essentiellement ADA en 1° année, et du C à la fin.
Un peu de C++ en 2° année, +asm, et bcp de merise / analyse OO (=> dégout).
C/C++ en Licence (reconcilliation C++), et un peu FORTRAN, Scheme (juste assez pour détester).
Maitrise : un poil de Java (réseau)
DESS: un poil de Java SWING (IHM)

Bref, quasiment rien après bac+3.

Un bouquin que j'ai beaucoup apprécié, et qui traite du "fossé entre le monde académique et le monde professionnel" : "Métier Développeur : kit de survie", de Jean-Christophe Arnulfo. C'est pas mal axé C++ & Windows quand même. A faire lire par les maîtrise / DESS.
Très instructif pour les étudiants. Ca permet de voir un peu en pratique ce que donne le génie logiciel.

Sinon à lire absolument :
Les cours et tutoriels pour apprendre C++ : http://cpp.developpez.com/cours/
La FAQ C++ : http://cpp.developpez.com/faq/

[merrheim]

yaka c'est sûr mais les makefiles si on veut que les étudiants aient compris et aient pratiqués, ça "bouffe" encore 4h de cours/TP ! Idem pour savoir utiliser un débogguer...et ainsi de suite avec des tonnes d'outils....
Et après, une fois qu'on a fait tout ça on s'aperçoit que les étudiants n'ont pas acquis les bases : on a passé trop de temps sur les outils et pas assez sur le fondamental.
Il y a des facteurs qu'il faut prendre en considération :
- les étudiants ne peuvent pas "absorber" un grand nombre d'outils comme ça surtout avec le nouveau public universitaire de ces 3-4 dernières années
(peut être ne saviez vous pas que notre public change ?)!
- si on manipule pas fréquemment les outils, on oublie très vite surtout quand on est étudiant.
- si on fait trop de choses on laisse 50 % de gars sur la route qui termineront chomeurs
- si on va plus lentement et avec pédagogie : on en a que 10 % c'est mieux !
Les entreprises préfère l'approche élitiste (on met tout au programme et les gars qui suivant pas on s'en fout) car elles ne s'intéressent qu'aux meilleurs étudiants que produit le système.
C'est sûr qu'il y a un fossé d'incompréhension avec un mépris caractérisé
envers le monde universitaire. Il n'est pas sans défaut, j'en suis bien conscient mais ce que je puis vous assurer c'est que tous mes étudiants qui ont fait un stage en développement, et parfois de pointe, on toujours donné 100% satisfaction aux entreprises.
A vouloir casser du prof on finit par dire n'importe quoi !
Facile

[kadirou]

Bonjour

Je ne vais pas vraiment participer au débat, car les sujets de discussion de ce topic sont devenus nombreux au fil des réponses (C/C++, outils, méthodologie, etc.)
Je voudrais juste rappeler que le but de ce cours est d'apprendre à des étudiants à programmer en C/C++. On peut discuter longtemps de ce que c'est C et de ce que c'est C++, des outils, etc mais il ne faut pas oublier que c'est des étudiants jeunes qui pour certains n'ont jamais programmé, et qui sont limité en temps. Quand on fait un cours, on s'adresse à un public assez large et c'est beaucoup plus facile de critiquer un cours que d'en construire un qui soit adapté à un plus grand nombre d'étudiants. Un cours n'est pas un tutorial et tant qu'on n'en n'a pas fait un, on sous-estime souvent le travail que ça nécessite.
Une petite remarque, beaucoup de profs ont constaté que commencer par l'OO passe mal, et préfèrent faire une transition (plus ou moins longue) par un langage procédural avant d'attaquer l'OO.

Cordialement

PS : >>merrheim : je pense qu'une idée d'amélioration est de faire évoluer le contenu du cours par les étudiants en fin d'année pour voir leurs réactions et attentes, car c'est eux (et les enseignants qui participent à ce cours) qui y participent réellement.