Commentaires sur la pédagogie

Le programme des séances est sérieusement modifié par rapport à 1998, pour deux raisons : le nombre de séances (ramené de 12 à 10) et le changement de langage.

Le passage de C à C++ est en partie motivé par la réduction du nombre de séances : il fallait trouver un langage plus simple à enseigner que C. Évidemment, C++ est beaucoup plus complexe, et il n'est pas question d'enseigner C++, mais seulement de l'utiliser. L'autre motif est que les élèves sont de plus en plus souvent amenés à programmer en C++ dans les stages, dès le 3ème trimestre, et qu'il vaut mieux qu'ils aient tous une connaissance minimale de ce langage, qui pourra être complétée au 2ème trimestre, pour ceux qui le souhaitent.

L'utilisation de C++ pose des problèmes pratiques que j'avais sous-estimés : absence de doc en ligne (pas de man pour les bibliothèques), et messages souvent abscons de g++ et de gdb, quand le programme utilise des classes. J'ai cependant installé comme doc une version presque définitive des spécifications ISO (versions PDF et hypertexte) du langage, y compris des bibliothèques standards : ce n'est guère utilisable par les étudiants, à cause des templates et des classes.

Pour toutes ces raisons, il faut voir le cours de cette année comme une transition vers un cours basé sur Java, déjà utilisé à l'X, sémantiquement beaucoup plus clair et enfin débarassé des archaïsmes de C. On a un an pour le préparer, et l'expérience C++ de cette année sera utile.

Il faut s'en tenir à un sous-ensemble de C++ (C mieux) et abandonner autant que possible les archaïsmes de C en profitant des simplifications de C++. Voici quelques évolutions.

• Mettre en évidence des notions qui ont déjà leur importance dans ce sous-ensemble de C++, dès le début : objets, sous-objets, valeur, expression gauche (lvalue).
• Ne plus utiliser int comme un booléen mais le type bool
• Ne plus utiliser de macros (même pas pour les constantes)
• Ne pas utiliser le passage par adresse (avec un type *) de C, mais le passage par référence (type &, accolé au type, pas au paramètre) de C++ ; tous les struct doivent être passés par référence, et les arguments d'entrée comme des const ; concerne aussi bien les arguments que l'objet retourné, mais avec plus de précautions dans ce dernier cas
• Ne plus utiliser l'opérateur & de C (pour un tableau, je préfère t+1 à &t[1])
• Utiliser les définitions de struct et d'enum de C++ (rendant inutiles le typedef usuel en C)
• Ne plus utiliser le cast de C, mais le cast fonctionnel de C++, c'est-à-dire employer double(2) au lieu de (double)2
• Réserver le typedef pour déclarer des noms de type dans certains cas, notamment pour des casts fonctionnels
• Ne pas utiliser les printf et scanf de C, mais les << et >> de C++ ; dans un premier temps sur cin et cout, dans un second temps sur les flots des classes istream, ostream, ifstream, ofstream, fstream (attention : les flots sur string ne figurent pas dans g++) ; renoncer à des formats trop contraints (alignements, etc ...)
• Ne pas utiliser malloc, free et realloc, sizeof, mais new, new[], delete, delete[] ; limiter les pointeurs aux tableaux dynamiques et aux structures chaînées (attention : g++, comme gcc, accepte les tableaux de taille variable sur la pile, ne pas en profiter).
• Ne pas représenter les chaines comme des char[], mais comme des strings (quelques exceptions : argv, fstreams).
• Utiliser les constructeurs et méthodes des strings et streams, en signalant que c'est différent
• Les en-têtes de C doivent être inclus sous la forme <c...>, par exemple, <cmath> et non <math.h>
• Exclus : les définitions de classes, de templates et de namespaces (sauf peut-être les namespaces anonymes, préférables aux globales static de C), la STL.
• En option : présenter le traitement des exceptions de C++ avec des types d'exception prédéfinis.

Le poly a été assez largement remanié pour tenir compte de cette évolution. Il contient des questions optionnelles ou qui peuvent servir de base à des projets. L'ordre des sections n'est toujours pas optimal et ne correspond pas exactement à l'ordre des séances que je propose. En particulier, je pense que l'on devrait introduire les struct plus tôt, avant les tableaux. Ceux-ci tendent d'ailleurs à devenir obsolètes, les types de la STL étant préférables pour une programmation sérieuse ; mais comme la STL est hors programme, il faut bien les enseigner. Le traitement de la modularité ne pouvant pas être fait sérieusement dans ce sous-ensemble de C++, autant ne pas perdre du temps en cours avec le découpage des programmes en fichiers (les élèves pourront le faire pour leurs projets).

Quelques suggestions de contenu plus détaillé pour chaque séance :

1. Donner un exemple assez conséquent (comme le calcul de pi), l'édition sous Emacs, la compilation sous Emacs, puis ddd
2. Les notions de base de syntaxe et de sémantique (expression, valeur, objet, etc) ; détailler les structures impératives (itérations) ; l'initialisation
3. Tout sur les fonctions, avec passage par valeur (dire que le passage des arguments se fait par initialisation des paramètres) ; parler de bloc, de portée, de variables locales ; d'allocation sur la pile, de blocs d'activation, d'empilage et de dépilage ; de récursivité
4. Types de base et construction de nouveaux types, exemple le struct complexe, le passage par valeur pour tous les types d'objet ; le passage par référence avec les types réf (qui ne sont pas des types d'objet) ; cas des struct, passage par const réf.
5. Tableaux 1D, fonction sur les tableaux 1D, tableaux 2D, fonctions, différences entre tableaux et struct ; où caser les strings ?
6. Pointeurs : ne pas les initialiser par &, mais par un new ou new[], ou par un tableau (dire qu'une fonction opère aussi bien sur un tableau automatique que sur un tableau dynamique) ; en priorité, faire les tableaux dynamiques ; les fichiers et les flots en général doivent être traités en TD, et aucun développement théorique n'est à faire, vu l'usage des classes de C++.
7. Expliquer l'idée des méthodes de construction (incrémentale, divide and conquer, programmation dynamique, ...) et traiter l'une d'elles
8. Expliquer la notion et l'intérêt des structures de données, distinguer l'interface et l'implémentation et choisir l'une d'elles (par exemple hachage et listes chaînées pour la recherche, ou arbres et piles pour le parcours)
9. la suite de la séance précédente
10. L'examen peut être limité à 1h30, ce qui libérerait du temps pour une 1/2-séance de cours.

URL: <http://cermics.enpc.fr/cours/info1/seances.html>