Discussion :

[gbdivers]

On choisi C++ quand on veut de la performance et un très haut niveau de personnalisation et d'optimisation.

En fait, c'est là la base du problème, je crois.

Non, ce n'est pas la seule raison de choisir le C++. Et même si c'est la raison (c'est mon cas, je recherche de la performance), tout le code n'est pas critique en terme de performance (j'utilise Qt pour l'IHM, moins j'ai a gérer manuellement pour cette partie, mieux ça me va ; pour d'autres parties du code, je suis intéressé par la méta programmation et les DSEL pour manipuler des concepts haut niveau, mais sans coût sur les performances).

Donc, la problématique principale dans le choix de la pédagogie a utiliser pour former au C++ dépend des objectifs et du public visés.

@Flob90 et @LucHermite : je préfère vous demander que demander à Google... c'est quoi des benchs ?

Benchmarks (tester les performances)

[Flob90]

@kaamui: Ce sont des mesures de performance. Tu réalises un contexte où appeler ta fonction à tester est réaliste, ensuite tu fais l'appel en mesurant le temps/la mémoire. Puis tu recommences suffisament de fois pour avoir une bonne mesure, puis tu changes de conteneur et tu recommences.

Edit: Grillé

[seeme]

En fait, c'est là la base du problème, je crois.

Non, ce n'est pas la seule raison de choisir le C++. Et même si c'est la raison (c'est mon cas, je recherche de la performance), tout le code n'est pas critique en terme de performance (j'utilise Qt pour l'IHM, moins j'ai a gérer manuellement pour cette partie, mieux ça me va ; pour d'autres parties du code, je suis intéressé par la méta programmation et les DSEL pour manipuler des concepts haut niveau, mais sans coût sur les performances).

Donc, la problématique principale dans le choix de la pédagogie a utiliser pour former au C++ dépend des objectifs et du public visés.


Benchmarks (tester les performances)

Je suis d'accord, ce ne sont pas les seuls raisons. Mais si on regarde uniquement le problème qu'on est sensé résoudre, on en revient souvent à ça. Par exemple, pour l'exemple que tu donnes, il aurait aussi été pertinent de faire l'ihm disons en python avec des appels c++.

Je veux dire par là qu'au coeur du problème, si le noyau dur est en c++ c'est souvent parce qu'on recherche la perf.

Mais je m'égare :p

[gbdivers]

Je suis d'accord, ce ne sont pas les seuls raisons. Mais si on regarde uniquement le problème qu'on est sensé résoudre, on en revient souvent à ça. Par exemple, pour l'exemple que tu donnes, il aurait aussi été pertinent de faire l'ihm disons en python avec des appels c++.

Je veux dire par là qu'au coeur du problème, si le noyau dur est en c++ c'est souvent parce qu'on recherche la perf.

Mais je m'égare :p

Je comprend moins là. Pourquoi je devrais apprendre le python pour faire une IHM alors que je peux la faire aussi bien en C++ ? De plus, en terme de productivité, j'irai aussi vite à créer une fenêtre en Qt qu'avec d'autres langages et framework.
Le C++ est un langage qui permet le bas niveau et les performances, ça ne veut pas dire qu'il ne peut faire que ça.

[Kaamui]

@kaamui: Ce sont des mesures de performance. Tu réalises un contexte où appeler ta fonction à tester est réaliste, ensuite tu fais l'appel en mesurant le temps/la mémoire. Puis tu recommences suffisament de fois pour avoir une bonne mesure, puis tu changes de conteneur et tu recommences.

Edit: Grillé

j'ai trouvé ça dans la FAQ, ce n'est pas suffisant pour se décider quand on cherche la performance ? Du coup, "le plus adapté" != "le plus performant dans ce cas là" ?

[pyros]

Par contre, l'approche "bas niveau" n'entre-t-elle pas en contradiction avec les reproches que l'on entend souvent avec les formations universitaires ? (à savoir, former des théoriciens, qui n'ont aucune idée de comment ça se passe dans "la vraie vie", qu'il faut former quand ils entrent dans l'entreprise)

Tout à fait d'accord, mais il ne faut pas aussi tomber dans l'autre extrème, c'est à dire une formation tellement pratique et spécialisée sur le besoin actuel des entreprises qu'elle sera obsolète dans 5 ans. Le genre de formation que proposent les école privé à la mode qui promettent 95% d'embauche à la sortie... J'aimerai connaitre le taux de reconversion des élèves 5 ans après quand même...

Le compromis idéal étant très difficile à atteindre, je préfère avoir un étudiant théorique capable d'évoluer car possédant de bonne base qu'un étudiant pratique verrouillé dans son domaine.
Après j'ai peut être une vision à trop long terme et je comprends que certains recruteurs préfèrent quelqu'un d'opérationnel tout de suite, quitte à la changer plus tard.

[seeme]

Je comprend moins là. Pourquoi je devrais apprendre le python pour faire une IHM alors que je peux la faire aussi bien en C++ ? De plus, en terme de productivité, j'irai aussi vite à créer une fenêtre en Qt qu'avec d'autres langages et framework.
Le C++ est un langage qui permet le bas niveau et les performances, ça ne veut pas dire qu'il ne peut faire que ça.

Non non ce n'est pas ce que je veux dire. Je me suis mal exprimé. Je ne dis pas qu'on ne peut que faire de la perf, on peut bien entendu faire pleins d'autres choses :p

Je veux dire qu'à priori ton choix s'est porté sur c++ parce qu'au coeur du problème tu as probablement besoin de perf (je parle en général), tu n'as pas choisis C++ à cause de l'IHM. L'utilisation ce C++ pour l'ihm n'est qu'une conséquence de ce choix.

[gbdivers]

Non non ce n'est pas ce que je veux dire. Je me suis mal exprimé. Je ne dis pas qu'on ne peut que faire de la perf, on peut bien entendu faire pleins d'autres choses :p

Je veux dire qu'à priori ton choix s'est porté sur c++ parce qu'au coeur du problème tu as probablement besoin de perf (je parle en général), tu n'as pas choisis C++ à cause de l'IHM. L'utilisation ce C++ pour l'ihm n'est qu'une conséquence de ce choix.

C'est pas mieux
Ce que tu veux dire, c'est que comme j'ai fait le choix du langage C++ pour des raisons de performances, je dois appliquer ces critères à l'ensemble de mon code, même là où il n'y en a pas besoin ?
Dans ce cas, clairement non Je veux être libre d'avoir de critères performance là où j'en ai besoin et des critères de productivité à d'autres endroits si je le souhaite.

Mais je pense avoir compris ton idée

[seeme]

C'est pas mieux
Ce que tu veux dire, c'est que comme j'ai fait le choix du langage C++ pour des raisons de performances, je dois appliquer ces critères à l'ensemble de mon code, même là où il n'y en a pas besoin ?
Dans ce cas, clairement non Je veux être libre d'avoir de critères performance là où j'en ai besoin et des critères de productivité à d'autres endroits si je le souhaite.

Mais je pense avoir compris ton idée

Je vais donc arrêter de patauger dans ma verve

[Flob90]

j'ai trouvé ça dans la FAQ, ce n'est pas suffisant pour se décider quand on cherche la performance ? Du coup, "le plus adapté" != "le plus performant dans ce cas là" ?

En théorie, oui c'est le mieux, en pratique pas forcément.

[Freem]

@Flob90 et @LucHermite : je préfère vous demander que demander à Google... c'est quoi des benchs ?

Comment on procède ?

@LucHermite : comment savoir quels sont les types non RAII ?

PS : encore des notions qu'on n'apprend pas à l'école...

RAII: Resource Acquisition Is Initialisation.
En gros, celui qui initialise une ressource l'acquiert. Et devra donc très probablement la nettoyer lui-même . (+ de 95% du temps, amha)

[dolanor]

En théorie, oui c'est le mieux, en pratique pas forcément.

Exactement.
Je m'étais aussi basé dessus lors d'un entretien de mission. La personne qui m'interrogeait état un professionnel ayant beaucoup travaillé sur C++, bref, il connaissait comme sa poche.
J'adore le C++, mais je n'ai pas (encore) la connaissance de tout. Et j'avais donc cet a priori de plus performant en insertions au milieu pour les list. (car implementées en liste chainées).
Seulement, apres plusieurs indices qu'ils m'a donné, je n'ai pas reussi a comprendre que lors d'une insertion, il faut reallouer de la memoire, et idem en suppression, il faut désallouer la mémoire. Alors qu'un vecteur, sa mémoire sera allouée pour X entrées (avec reserve() notamment). Du coup, pour qu'un vecteur soit moins efficace qu'une liste, il faut qu'il manipule des milliers voire des millions d'elements pour que la charge CPU d'un déplacement d'elements dans le vecteur soit plus forte que l'allocation/desallocation mémoire d'un nouvel objet a inserer dans une liste.

Ce serait pas mal de mettre ce tableau de la FAQ à jour à ce sujet du coup, non ?

[koala01]

Ce n'est pas tant du NIH que du "les premières versions datent d'avant l'introduction de ces fonctionnalités dans le standard et il faut maintenant supporté l'historique".

Je suis bien conscient que c'est du à un aspect historique de Qt, mais le résultat reste le meme, malgré tout, meme si la norme est de mieux en mieux prise en charge (je pense, par exemple, aux moyens de passer de QString à std::string, ou aux nouvelles futures fonctionnalités de la version 5 )

Mais, si j'ai un regret vis à vis de Qt (dont je ne remet nullement la qualité en question, ceci dit ), c'est que le projet a peut etre été lancé... un ou deux ans trop tot, à une époque où les compilateurs étaient encore tous loin de respecter une nomre à peine sortie

Personnellement, cela ne me choque pas plus que ça que la STL ne soit pas enseignée (j'ai d'ailleurs découvert la STL une fois diplômé seulement). Si on enseigne la STL, pourquoi ne pas enseigner QT, BOOST ou n'importe quelle autre framework ? Bien qu'elle fasse partie des spec du langage, elle s'utilise comme n'importe quelle autre lib.

Déjà, il faut quand meme se rendre compte que le framework S(T)L fournit, essentiellement, des concepts "basiques":
les concepts memes de chaine de caractère, de tableau, de pile, de file, de table de hashage, d'arbre binare, de différents algorithme de tri ou de recherche font, à mon sens, partie de ce que l'on pourrait appeler les "principes de base de la programmation" et existent, d'une manière ou d'une autre (quitte à souffire du syndrome du NIH ) dans tous les langages impératif de troisième génération

Un étudiant sachant utiliser une librairie quelconque saura utiliser la STL, et surtout il saura s'en passer si elle n'est pas disponible. Il comprendra aussi pourquoi le std::vector n'est pas un conteneur magique et pourquoi ses perf s'effondre quand il le remplis à coup de push_back.

Un étudiant ayant été formé a utiliser la STL dès le début ne saura plus quoi faire s'il n'a pas son précieux std::vector sous la main. Il faut arrêter de penser que la STL est un acquis absolue toujours disponible en toute circonstance.

Après, il faut aussi faire la différence entre ceux qui se contentent de ce qu'ils connaissent et continue à faire des new int[...] à outrance, et ceux qui comprennent tout l'intérêt d'utiliser des choses nouvelle plus haut niveaux.

Attention, on ne dit nullement qu'il ne faut enseigner que la STL en occultant, d'une manière ou d'une autre, la gestion manuelle de la mémoire ou le moyen de réimplémenter une liste personnelle

Je crois que tout le monde plaide pour qu'il y ait, au minimum, une approche sur les deux points de vue (haut niveau avec std::vector et autres conteneurs, et une approche bas niveau avec gestion dynamique de la mémoire )

Mais, à titre perso, je préférerais que l'on aborde, en priorité, la S(T)L pour permettre de faire le parallèle entre les conteneurs qu'elle fournit et les concepts qu'elle soutient, et de reporter l'approche "bas niveau" à un moment où, ayant "maitrisé" les conteneurs, la gestion manuelle de la mémoire s'avère plus intéressante encore que le simple fait d'avoir trois entiers contigus en mémoire : Le moment où l'on va, par programmation décider du type réel d'une donneé sur base d'informations obtenues par ailleurs (héritage et polymoprhisme inside )

Je pensais plus au fait qu'un étudiant ayant apris dès le début à utiliser un std::vector se contera des faire des push_back sans trop réfléchir (allez-pas me faire croire que l'étudiant vas allez lire la doc pour voir ce que ça implique).

C'est là que l'on fait la différence entre un étudiant "passionné" et un étudiant qui attend avec impatience la fin des cours

Un étudiant ayant appris à faire des new et gérer sa mémoire à la main est plus sensibilisé au fait qu'on ne fait pas ce qu'on veut avec la mémoire et se posera peut être plus de question sur ce qu'il se passe en interne.

à condition toute fois que le cours qui lui a appris à gérer la mémoire à la main ait été bon

Plus sérieusement...

L'apprentissage de la STL ne devrait pas se limiter au seul apprentissage de std::vector, mais devrait, à tout le moins, indiquer qu'il existe différents conteneurs (et lesquels) adaptés à différentes situations, tout comme un apprentissage de la gestion manuelles de la mémoire devrait mettre en évidence les bienfait qu'il peut y avoir à utiliser les différents concepts (tableau d'éléments contigus, liste, pile, file, arbres binaires et autres )

Je pense qu'il vaut mieux enseigner le C++ pur et dire qu'il existe des lib plus haut niveaux (en parlant de la STL bien sûr) disponible la plupart du temps. Cela rend les étudiants peut être moins opérationnel dès le début, mais plus polyvalent et plus "malléables" au sens où comme ils n'ont pas encore leurs petites habitudes et leur lib préférées qu'ils ont appris à l'école, ils adoptent plus facilement les conventions utilisées dans leur boulot. Une lib s'apprend sur le tas en fonction de la politique et des contraintes de l'entreprise.

A titre personnel, si je devais tomber dans un projet de moins de cinq ans pour lequel la STL a été volontairement écartée (donc, en excluant toutes les situations dans lesqelles elle n'est simplement pas disponibles ), je refuserais de travailler pour le projet

Je comprend ton point de vue dans le sens où, contrairement à d'autres langages, C++ devient particulièrement efficace grâce aux bibliothèques / frameworks extèrnes et donc dans le sens où il est bon, de manière générale, qu'un étudiant puisse apprendre à intégrer une bibliothèque externe dans son projet (et qu'il s'y soit frotté une première fois, si possible )

Par contre, je le répète, la S(T)L ne fait que fournir une implémentation, peut etre perfectible, de concepts que l'on retrouve dans n'importe quel langage de troisième génération, tel que des algorithmes et des structures de conteneurs classiques...

Il est vraiment dommage que l'étude de C++ ne passe pas par une approche minimal de ce que cette bibliothèque, sensée être disponible avec n'importe quel compilateur, est en mesure d'apporter, ne serait ce qu'en terme de qualité et de sécurisation du code

[oodini]

Quant à la partie sur le documentation, je trouve qu'une doc simple orienté débutant qui expose bien chaque point délicat du c++ en français ça manque.

Le livre de Deitel.

[jeanlou]

En ce qui me concerne, ayant débuté dans le domaine en 1976 (!), j'ai difficile à me satisfaire utilisant la version Visual C++ 2009 !
Le problème m'incombe, car j'ai abandonné le plaisir de programmer durant plus de 15 années, cause: obligations professionnelles !

Ce que je déplore le plus, c'est le surplus de bibliothèques obsolètes !
Dans les années '80-'90, j'avais un énorme plaisir à créer 'moi-même' (!), les fonctions spécifiques à mes propres besoins.
Je pouvais écrire un programe de plusieurs milliers de lignes, après compilation, il suffisait d'un petite disquette pour le copier !

Quand est-il aujourd'hui ? Bientôt il faudra un Blu-Ray !

Évidemment, si j'avais pu suivi l'évolution d'année en année, j'aurais un autre optique, mais voilà...c'est dur à reprendre, même ayant des bases professionnelles.

J'en suis à la moitié du livre d' Ivor Horton "Visual C++ 2008" et c'est difficile, mais je n'abandonne d'aucune façon !

Quelqu'un a-t-il connu l'époque des mag de COBB ' Inside Microsoft C ' ?
C'était très convivial et instructif.
PS: Excusez mes fautes d'ortographes éventuelles, je suis néerlandophone !
Jean

[oodini]

Je veux dire qu'à priori ton choix s'est porté sur c++ parce qu'au coeur du problème tu as probablement besoin de perf (je parle en général), tu n'as pas choisis C++ à cause de l'IHM. L'utilisation ce C++ pour l'ihm n'est qu'une conséquence de ce choix.

Le souci de performances peut ne concerner que 20 % de ton code.
Pourquoi s'emm* à gérer des allocations mémoires dans les 80 autres % si tu peux utiliser des conteneurs de la STL ?

[Luc Hermitte]

@LucHermite : comment savoir quels sont les types non RAII ?
PS : encore des notions qu'on n'apprend pas à l'école...

Dans le standard, en gros tous les pointeurs bruts, plus les types ressources hérités du C (-> FILE) (& POSIX -> sockets, ...).
Je t'invite à regarder la FAQ. Si ton prof était au point, il t'a peut-être présenté le concept sans introduire le mot clé.

Mais c'est une situation classique : ils préfèrent montrer la syntaxe et le monde C plutôt que d'enseigner le développement robuste dans un contexte C++ où les exceptions existent. Si tant est qu'ils soient initiés à la gestion des ressources et aux situations exceptionnelles en C++.

On choisit C++ quand on veut de la performance et un très haut niveau de personnalisation et d'optimisation. C'est donc critique de connaitre toute cette partie bas niveau. D'après moi on part de plus loin avec C++ donc on met plus de temps avant d'arriver à se poser la question de la STL.

Un enseignant n'est pas là pour rendre le langage sympa. Il est ce qu'il est et il faut l'enseigner tel qu'on l'utilise.

Un enseignant est là pour inculquer les bonnes pratiques.
Et il est plus important pour un élève de disposer de bonnes pratiques qui assurent du code robuste, que de survoler les détails de la gestion de la mémoire en C (cf plus haut -> en C++ il ne faut pas oublier les exceptions, et donc le RAII) et avoir du code qui va très vite .... dans le mur.
Ca on en veut pas. Quand on met des développeurs dans une batterie pour pondre au KLoC du code, la (micro souvent) optimisation induite par vector vs list vs new[] est bien moins pertinente que la robustesse. Un ou deux plus experts que les autres, ou une seconde phase de réglages suffisent amplement pour régler ces détails. Et cela coutera moins cher que la chasse aux fuites et aux segfaults.

[oodini]

C'est là que l'on fait la différence entre un étudiant "passionné" et un étudiant qui attend avec impatience la fin des cours

Où un étudiant dont les études sont payées par les parents et qui a le temps de se faire des petits projets persos, et un autre qui doit bosser chez MacDo pour payer son appart et ses nouilles.

[gbdivers]

Où un étudiant dont les études sont payées par les parents et qui a le temps de se faire des petits projets persos, et un autre qui doit bosser chez MacDo pour payer son appart et ses nouilles.

C'est un argument que j'ai déjà entendu... et qui m'énerve au plus haut point : si un étudiant ne fait pas de travail personnel, c'est qu'il a pas envie. Point.
(et je précise que j'ai fait toutes mes études en travaillant presque à plein temps ; et j'ai quand même trouvé le temps de faire des stages en licence et en maîtrise pendant toute l'année)
Mais on est hors sujet là...

[seeme]

Le souci de performances peut ne concerner que 20 % de ton code.
Pourquoi s'emm* à gérer des allocations mémoires dans les 80 autres % si tu peux utiliser des conteneurs de la STL ?

Ce n'était absolument pas mon propos. A aucun moment j'ai dit qu'il fallait ou non utiliser la STL pour telle ou telle partie. Ce post concernait le choix du C++ pour l'ihm.

Merci de ne pas le sortir de son contexte.