Discussion :

[screetch]

(sinon vous avez une définition de "tous" dans "Nous sommes tous conscients" qui est plutot "tous sur ce fil", pas "tous sur le forum"

[Goten]

ben non c'est pas si simple, pour moi quelqu un qui code en C++ doit savoir faire sa propre classe vector, c'est un cours simple de programmation. c'est aussi un exempe qui montre le RAII, le code exception-safe, le passage par référence, et quelqu un qui ne sait pas faire ca n'a pas toute les armes pour faire ses propres outils (ce qui est la base du C++)
exemple : j'ai beau chercher je ne vois pas de std::quadtree, struture universelle en jeux vidéos.

Certes certes on est d'accord, c'est toujours un bon exercice, je suis passez par là et je pense que je suis pas le seul.
Mais, pour moi c'est pas la première chose a apprendre, loin de là autant savoir ce servir des outils qui ont était testé et approuvé, pis quand on rentre dans le vif du sujet (quand on a traité les allocators et les algorithmes utile pour ce genre de classe) alors pour ne pas se faire la main sur un vector like?
De toute façon comment implémenté une feature que tu connais pas ou peu?

J'en veux pour preuve que l'ouvrage qu'on cite souvent comme référence AC++ a tout un chapitre dédié à la création d'une classe vector like.
Ce qu'on dit c'est que c'est pas par ça qu'il faut commencer loin de là.


Edit : par tous j'entendais : il me semble que la plus part des intervenants régulier du forum le savent ...
toute personne qui a lu les gotw le sait de toute façon :p. (et qui n'a pas lu les gotw..)

[screetch]

toute personne qui a lu les gotw le sait de toute façon :p. (et qui n'a pas lu les gotw..)

tiens j'ai pas lu celui la je crois

[Goten]

Pardon? (tu fais référence à quoi en fait? :p)

[screetch]

(désolé, j'ai édité pour clarté)

[koala01]

ben non c'est pas si simple, pour moi quelqu un qui code en C++ doit savoir faire sa propre classe vector, c'est un cours simple de programmation. c'est aussi un exempe qui montre le RAII, le code exception-safe, le passage par référence, et quelqu un qui ne sait pas faire ca n'a pas toute les armes pour faire ses propres outils (ce qui est la base du C++)

Effectivement, le fait de devoir créer sa propre classe vector ou sa propre classe string est un exercice de style des plus intéressant en terme d'apprentissage.

Mais, dans les premiers temps de l'apprentissage, le fait que std::string et std::vector soient RAII et exception-safe nous permet justement de "laisser ces problèmes pour plus tard" (comprend: pour quand l'étudiant aura eu un peu plus que trois ou quatre heure de cours)...

exemple : j'ai beau chercher je ne vois pas de std::quadtree, struture universelle en jeux vidéos.

Universelle en jeux vidéo, mais peut être un poil spécialisée

Quand tu y regarde bien, le contenu de la S(T)L a vocation strictement générale: tout le monde manipule (ou manipulera tôt ou tard) des collections, des flux, des chaines, ou des pointeurs

En dehors du domaine des jeux vidéo, les raisons d'utiliser des quadtree sont *relativement* limitées

(sinon vous avez une définition de "tous" dans "Nous sommes tous conscients" qui est plutot "tous sur ce fil", pas "tous sur le forum"

Par tous, j'entends:

• Ceux qui interviennent sur ce fil
• Ceux qui interviennent de manière régulière sur cette partie du forum (et qui ne sortent pas trop d'inepties)

Ceci dit, je n'ai pas fait une grande école réputée pour avoir mon équivalent BAC+4 en informatique (j'ai suivi des cours du soir ), et je vois peut être les choses du mauvais coté de ma lorgnette, mais voici l'expérience que j'en ai eue:

Mon prof de C++ était plein de qualités: ingénieur, excellent en math et en sttats et très calé en C.

Par contre, ses talents en conception étaient très moyen et sa connaissance du C++ laissait très largement à désirer (du moins, si je fais la comparaison avec le niveau que j'ai acquis et que je continue d'acquérir grâce au forum).

Le résultat, c'est que, alors que je m'étais déjà très largement intéressé à la S(T)L, je bondissais littéralement sur ma chaise chaque fois qu'il présentait un code qui était, au final, sacrément proche du C with class.

Tu te demande peut être ou je veux en venir, mais j'y arrive: Finalement, combien y a-t-il de prof de C++ qui donnent ce cours uniquement parce... qu'il connaissent le C, et parce qu'ils sont persuadés (aussi bien eux que la direction de leur établissement) que C et C++, c'est finalement pareil, ou à défaut "tellement proche que l'on peut les amalgamer"

Je l'ai dit plus haut, mon prof était plein de qualités, et celle que j'ai le plus appréciée, c'est qu'il acceptait, à condition de lui présenter les bons arguments, de se remettre en question.

Si bien qu'il a commencé à s'intéresser d'un peu plus près à la STL en fin d'année (il faut dire que j'avais généralement des arguments pour le moins valables )

Je ne sais pas ce qu'est devenu son cours par la suite, mais, s'il a évolué de la manière dont je l'espère, voilà sans doute un prof qui relèvera considérablement le niveau de ses étudiants en C++.

Tout cela pour dire qu'il ne nous appartient sans doute pas de "juger" la manière dont un prof donne son cours.

Par contre, s'il est possible, avec les bons arguments, de l'inciter à se remettre en question afin de faire évoluer son cours de C++ vers un cours totalement distinct du C et présentant, en priorité, les facilités du langage, je trouve réellement que l'investissement en vaut la peine

[CedricMocquillon]

[HS limite Troll] Le problème c'est que le temps que les profs de bonne volonté se mettent à jour, la nouvelle norme sera bien supportée dans les compilateurs Je sens que dans quelques temps on refera un post sur C++03 vs C++0x [/HS limite Troll]

[Goten]

tiens j'ai pas lu celui la je crois

http://www.gotw.ca/gotw/084.htm

(au cas où.... car le titre est pas indicatif dans notre cas)

[koala01]

[HS limite Troll] Le problème c'est que le temps que les profs de bonne volonté se mettent à jour, la nouvelle norme sera bien supportée dans les compilateurs

A vrai dire, la nouvelle norme va principalement faire deux choses:

• Pérenniser ce qui a été fait avec TR1 (en faire remonter le contenu de std::tr1 vers std)
• fournir quelques features qui sont apparues utiles (indispensables ) avec le temps

Si, malgré la nouvelle norme, tous les profs venaient déjà à apprendre du C++ correct issu de C++03, ce serait déjà un grand bond en avant

Je sens que dans quelques temps on refera un post sur C++03 vs C++0x [/HS limite Troll]

Je ne crois pas... C++ reste C++, qu'il suive la norme 03 ou 0x.

Bien sur, tu auras l'incompatibilité potentielle d'un code orienté 0x si tu essaye de le compiler en 03, mais le problème inverse n'existera pas

[Cheps]

(j'ai juste survolé le sujet, désolé si ça a été déjà dit)

Personnellement, je ne pense pas qu'il soit possible d'enseigner le C et C++ dans le même cours (surtout que les semestres universitaires sont assez courts). Ce sont clairement des langages qui s'utilisent différemment. A l'enseignant de faire le bon choix.

Pour ce qui est du C++, il me semble logique de commencer avec des tableaux, char*, etc, même si en pratique ça ne s'utilise pas. Ne serait-ce que si l'étudiant doit un jour modifier du code C++ programmé "à la C", ou doit s'interfacer avec une bibliothèque C (e.g. OpenGL). Dans ce cas, avoir utilisé des vecteurs sans connaître les tableaux serait fâcheux...

[loufoque]

Quel est l'intérêt du C alors ?

Le choix d'un langage, c'est avant tout une affaire de goût.
Certains trouvent que C fournit juste ce qu'il faut d'abstraction et que C++, avec ses possibilités d'abstraction plus élevées, permet trop facilement d'écrire du code inefficace.

Bien entendu, C++ n'est pas "plus lent" que C, C++ peut générer du code tout autant efficace que C, et même plus dans certains cas.

[koala01]

Pour ce qui est du C++, il me semble logique de commencer avec des tableaux, char*, etc, même si en pratique ça ne s'utilise pas. Ne serait-ce que si l'étudiant doit un jour modifier du code C++ programmé "à la C", ou doit s'interfacer avec une bibliothèque C (e.g. OpenGL). Dans ce cas, avoir utilisé des vecteurs sans connaître les tableaux serait fâcheux...

J'aurais plutot l'approche inverse: voir en priorité std::string et vector, vu que ce sont les deux classes dont tu parles, puis voir comment l'interfacer avec une bibliothèque C, étant donné qu'il est, finalement, très facile d'envoyer le contenu d'une chaine ou d'un tableau C++ sous la forme d'une chaine ou d'un tableau "C style" (c_str() et & tab[0] inside)

[screetch]

mais n'est-ce pas utiliser std::string comme un "golden hammer" sans comprendre ses avantages ou ses inconvénients ?
j'ai l'impression que plus je connais le C++ moins j'utilise la STL, du moins quelques grosses conneries (selon moi) pour des classes beaucoup plus spécialisées.
bien sur c'est quelque chose qui vient avec l'experience

l'exemple avec le quadtree c'etait justement pour ca, montrer que dans la vie ya pas que la STL et que des fois il faut mettre les mains dans le cambouis.

[guillaume07]

mais n'est-ce pas utiliser std::string comme un "golden hammer" sans comprendre ses avantages ou ses inconvénients ?
j'ai l'impression que plus je connais le C++ moins j'utilise la STL, du moins quelques grosses conneries (selon moi) pour des classes beaucoup plus spécialisées.
bien sur c'est quelque chose qui vient avec l'experience

l'exemple avec le quadtree c'etait justement pour ca, montrer que dans la vie ya pas que la STL et que des fois il faut mettre les mains dans le cambouis.

tu aurais un autre exemple, ça m'intérèsse

[Cheps]

J'aurais plutot l'approche inverse: voir en priorité std::string et vector, vu que ce sont les deux classes dont tu parles, puis voir comment l'interfacer avec une bibliothèque C, étant donné qu'il est, finalement, très facile d'envoyer le contenu d'une chaine ou d'un tableau C++ sous la forme d'une chaine ou d'un tableau "C style" (c_str() et & tab[0] inside)

C'est une question d'approche
En tous cas, je pense que commencer par de la programmation procédurale est bien plus simple que par de l'OO. Ceci qui n'exclut pas le C++ puisqu'on peut très bien se passer d'OO. Après quand à l'ordre d'apprentissage je préfère commencer par apprendre les tableaux et comment faire un bubble sort ou un quick sort, puis leur apprendre l'existence de <vector> et <algorithms> (ce qui n'arrive malheureusement jamais avec des débutants puisqu'un semestre universitaire est bien trop court).

[koala01]

C'est une question d'approche
En tous cas, je pense que commencer par de la programmation procédurale est bien plus simple que par de l'OO. Ceci qui n'exclut pas le C++ puisqu'on peut très bien se passer d'OO.

Bien sur que tu peux passer par l'apprentissage du procédural avant de passer à celui de l'OO... Et c'est même préférable.

D'ailleurs, tu n'a pas forcément besoin de savoir ce qu'est le paradigme de programmation générique pour apprendre à manipuler les collections

Mais, cela n'empêche que, si tu apprend C++ sous sa forme procédurale, cela ne t'empêche nullement de connaitre quelques classes de bases.

Tu ne te passera par exemple pas de cin sous prétexte que tu travaille en procédural

Après quand à l'ordre d'apprentissage je préfère commencer par apprendre les tableaux et comment faire un bubble sort ou un quick sort, puis leur apprendre l'existence de <vector> et <algorithms> (ce qui n'arrive malheureusement jamais avec des débutants puisqu'un semestre universitaire est bien trop court).

Attention, tu parles là de deux choses bien distinctes:

D'un coté tu fais intervenir une connaissance "théorique" de l'algorithmique, et de l'autre, tu parles de l'une des implémentations qui en est faite dans un langage particulier.

Comme je l'ai déjà dit, s'il y a, à mon sens, un prérecquis indispensable à l'apprentissage de n'importe quel langage de programmation procédural ou OO, c'est ce que je pourrais appeler la connaissance des "principes de programmation".

En gros, il s'agit d'avoir compris ce que signifient des termes comme

• type de donnée
• variable
• constante
• test ("vrai / faux" et à choix multiple)
• boucles (tant, jusque et incrémentale)
• structure définie par l'utilisateur
• pile
• file
• liste
• arbre binaire
• tableaux
• et d'autres encore (comme dicotomie, tri à bulle, tri par insertion, "quick sort", récursivité, etc)

leurs avantages, leurs inconvéniants et la manière de les utiliser (algorithmique inside).

J'aurais pu rajouter dans la liste des termes comme "flowchart" (quelle horreur), "nassi-schneiderman", "jackson", "pseudo code" (pas vraiment mieux que flowchart, si ce n'est que cela donne une bonne idée de ce à quoi pourra ressembler le code dans un langage réel) ou autres qui, justement, te permettent, sans passer par un langage donné, de comprendre la logique que tous les autres termes impliquent ou mettent en oeuvre.

Comme je l'ai déjà dit (il y a quelques pages), si tu comprends ces quelques principes, leur mise en oeuvre (quel que soit le langage envisagé) n'est plus qu'une question de grammaire et de syntaxe et se limite presque à un "long et fastidieux travail de dactylographie".

Alors, bien sur, il est important de permettre à l'étudiant de découvrir la manière dont il devrait coder un algorithme donné dans un langage donné, mais cela n'empêche nullement de le lui faire faire en utilisant directement les *bonnes* structures (tu peux coder un quick sort ou un tri à bulle "personnel" sur un std::vector, et tu peux très bien implémenter une fonction "personnelle" de recherche de sous chaine personnelle avec une std::string, sans pour autant aller excessivement loin dans l'apprentissage de ces classes )

[screetch]

tu aurais un autre exemple, ça m'intérèsse

un autre exemple de quoi ?

[Davidbrcz]

un autre exemple de quoi ?

Je pense qu'il parlait des parties de la STL que tu trouves foireuse.

[screetch]

mis a part les std::string, je classe aussi les flux dedans, j'aurai preferé ce que boost a, une chaine formattée comme un printf mais type-safe. Ce sont pour moi les deux gros inconvénients.

[ptyxs]

Jusqu'ici j'avais l'impression que les flux C++ étaient de magnifiques outils... qu'est-ce qui te chiffonne donc précisément avec les flux screetch?