(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" ;)
Version imprimable
(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" ;)
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.Citation:
Envoyé par screetch
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..)
tiens j'ai pas lu celui la je croisCitation:
toute personne qui a lu les gotw le sait de toute façon :p. (et qui n'a pas lu les gotw..)
Pardon? (tu fais référence à quoi en fait? :p)
(désolé, j'ai édité pour clarté)
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.Citation:
Envoyé par screetch
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)...
Universelle en jeux vidéo, mais peut être un poil spécialisée :question:Citation:
exemple : j'ai beau chercher je ne vois pas de std::quadtree, struture universelle en jeux vidéos.
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 ;)
Par tous, j'entends:Citation:
Envoyé par screetch
- 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" :question:
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 :D)
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 ;)
[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 :aie: Je sens que dans quelques temps on refera un post sur C++03 vs C++0x :ouin: [/HS limite Troll]
http://www.gotw.ca/gotw/084.htmCitation:
Envoyé par screetch
(au cas où.... car le titre est pas indicatif dans notre cas)
A vrai dire, la nouvelle norme va principalement faire deux choses:Citation:
Envoyé par CedricMocquillon
- 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 :question:) 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 :D
Je ne crois pas... C++ reste C++, qu'il suive la norme 03 ou 0x.Citation:
Je sens que dans quelques temps on refera un post sur C++03 vs C++0x :ouin: [/HS limite Troll]
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 ;)
(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...
Le choix d'un langage, c'est avant tout une affaire de goût.Citation:
Envoyé par maxim_um
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.
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)Citation:
Envoyé par Cheps
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èsseCitation:
Envoyé par screetch
C'est une question d'approche :PCitation:
Envoyé par koala01
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).
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.Citation:
Envoyé par Cheps
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 ;)
Attention, tu parles là de deux choses bien distinctes:Citation:
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).
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
leurs avantages, leurs inconvéniants et la manière de les utiliser (algorithmique inside).
- 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)
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 ;))
un autre exemple de quoi ?Citation:
Envoyé par guillaume07
Je pense qu'il parlait des parties de la STL que tu trouves foireuse.Citation:
Envoyé par 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.
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?
Ces pré-requis font parti de l'apprentissage, tu ne peux pas leur apprendre tout ça avant qu'ils aient codé la moindre ligne. Faut y aller de manière incrémentale à mon avis. Tu commences par entrées/sorties et déclaration de variables, hop ils font 2 exercices. Ensuite calculs simples et fonctions, hop 2 exercices. Ensuite conditions et boucles, hop 2 exercices. Voir et utiliser les vecteurs je suis pour, mais finir un cours d'introduction sans aborder les tableaux je suis contre (d'où mon "il faut choisir l'ordre"). Après ça dépend des étudiants et des objectifs du cours.Citation:
Envoyé par koala01
le formattage est peu clair, je n'aime pas devoir couper mes phrases au milieu. un exemple idiot, c'est que j'oublie toujours de rajouter un espace a la fin de mes mots lorsque la phrase devient découpée, du coup un nombre devient collé au mot qui le precede ou qui le suit. c'est aussi super mal foutu pour les traductions de texte. je prefere les chaines formattées. c'est un avis plus discutable que std::string, mais ca reste assez courant de ne pas aimer les flux.Citation:
Envoyé par ptyxs
Si, tu peux...Citation:
Envoyé par Cheps
Il est tout à fait possible de leur apprendre ces prérequis sans leur faire écrire une seule ligne de code dans n'importe quel langage de programmation existant.
Et je dirais même que c'est la meilleure approche possible: celle qui consiste à se dire que le langage de programmation n'est qu'un outil permettant de faire comprendre à quelque chose d'aussi bete que l'ordinateur ce que l'on attend de lui.
La conception (au sens le plus large, allant de l'analyse des besoins à la création d'algorithmes en passant par l'identification du contenu de structures ou par les interactions qu'il y a entre les différents éléments d'un programme, et j'en oublie surement) est tout un art, mais, normalement, lorsque tu écris ta première ligne de code, tout le travail réellement intéressant a déjà été fait ;)
Cela n'empêche nullement de revenir sur une étape ou une autre de la conception si, lorsqu'on commence à implémenter la solution, on se rend compte que l'on est passé "à coté de quelque chose", mais, pour autant que ton travail de conception tienne "la route" et que tu aies choisi une représentation pour tes algorithmes qui permette la "traduction immédiate" - ce qui n'est, effectivement, pas le cas du flowchart, mais qui est, par contre, celui du nassi-schneiderman, du moins, à mon sens, et malgré tout le mal que certains sur le forum peuvent en penser - tu pourrais presque demander à un ordinateur de se charger de l'écriture du code, parce que ce n'est qu'un travail de traduction et de dactylographie;)
Après tout, en dehors de la syntaxe propre à un langage particulier, un "quick sort" (par exemple) se fera en suivant exactement la même logique, que ce soit en C, en java, en C++ ou en Cobol...
Le gros problème de beaucoup de débutants (et sans doute de certains "pro"), c'est que, lorsqu'on leur demande d'écrire une fonction, ils se jettent sur leur clavier et commencent à "pisser du code" sans avoir pris la peine de réfléchir ne serait-ce que deux minutes à la logique qu'il faut mettre en oeuvre pour qu'elle fournisse le résultat attendu de la meilleure manière possible.
Le résultat, c'est que, non seulement, ils sont confrontés aux inévitables fautes de frappe, mais que, en plus, ils vont perdre un temps incroyable en débuggage, simplement parce qu'ils n'ont pas pensé plus loin que la troisième instruction qui suit celle qu'ils sont occupés à écrie.
Or, si tu réfléchis à ton algorithme avant d'écrire ta première ligne de code et que tu le teste mentalement (en te mettant à la place de l'ordinateur), si tu utilise la bonne méthode de représentation des algorithmes (comprend: celle qui ne laisse planer aucun doute sur la manière d'implémenter l'algorithme), la première compilation réussie (une fois corrigées les inévitables fautes de frappe et erreur de syntaxe) te donnera exactement le résultat attendu.
Ca peut ne pas être le résultat "optimum", dans le sens ou ton algorithme, n'est peut être pas le meilleur, mais le résultat correspondra à ce qui est attendu.
Je pense qu'il y a aux moins trois sujets distincts mais liés à ne pas confondre :Citation:
Envoyé par screetch
1 - Est-il nécessaire pour être autonome en C++ de savoir gérer manuellement la mémoire, être capable de réécrire une classe string ou vector...?
2 - Dans quel ordre présenter les différentes parties d'un cours de C++ (ce qui me semblait la question initiale de ce post)
3 - Faut-il utiliser dans la vie courante string, vector et cie plutôt que char*, allocation manuelle...
A 1, je répond sans hésiter oui. Mais à 2, je répond que la courbe d'apprentissage me semble beaucoup plus progressive si on commence par string/vector, et qu'on garde les choses plus manuelles pour la fin.
A la question 3, je répond oui par défaut. Ce qui vient renforcer mon point de vue sur la question 2, ce qu'on utilise dès le début fait moins peur que quelque-chose qui n'arriverait que dans la dernière leçon.
Au second ordre, elle est très mauvaise, certes. Mais au premier ordre, elle gère correctement ce pour quoi elle a été conçue : Gestion de l'allocation mémoire, de la taille, sémantique de valeur. On aurait pu faire une classe de string meilleure, mais la classe actuelle est quand même largement au dessus des alternatives de type char*.Citation:
Envoyé par screetch
Pour un néophyte total en prog, je pense que commencer par python est un très bon choix. Pas de C, pas de C++, rien de tout ça car ces derniers sont "trop proches du hardware". Il y a plusieurs années, on aurait commencé par le BASIC ou le logo (hé, vous avez connu ça ?)
Ensuite, quand vient le moment d'aborder le C++, avant le C, je conseillerai de commencer par les notions de scopes, de passage par copie ou référence le tout en manipulant des POD sur la pile et les objets de base de la SL, string, vector, io*. De ce coté là, effectivement, AC++ est un bon bouquin.
Aprés tout, quelles sont les choses importantes sur lesquelles il faut se focaliser dès le début quand un programmeur professionnel a la lourde tâche d'apprendre un nouveau langage ? Par quoi commencez-vous ?
En dehors de la syntaxe et de la grammaire propre au langage, je dirais (peut être dans un ordre différent)
- les type définis par l'utilisateur qu'il admet et leur particularités (par exemple: en C++, la seule différence entre une struct et une class tient dans leur accessibilité par défaut, en C#, par contre, une structure a d'office sémantique de valeur et est passée comme telle (avec copie) en argument, alors qu'une classe a d'office sémantique d'entité, et est passée sous une forme équivalente à la référence du C++)
- La manière de présenter le code source d'un "module" (un, ou plusieurs fichiers:question:, définitions incluses dans la déclaration ou séparée, ...)
- La manière de créer des collections
- La manière de gérer les chaines de caractères
- La manière de gérer les flux et ou les fichiers
- La manière de convertir les types primitifs en chaine et inversément
- Les classes, structures, fonctions libres fournies par le langage/le standard qui n'entre dans aucune des catégories sus-citées, mais en fonction de mes besoins (ce qui implique qu'il n'est pas exclu que je ne m'intéresse jamais à une fonction ou à une classe que je n'utilise jamais ;))
Problème: un semestre universitaire c'est 14 semaines, avec en principe 2 heures de cours et 2 heures d'exercices par semaine (en tous cas ici en Suisse, je ne connais pas le système français). Tu ne peux pas te permettre d'enseigner un "langage pour néophytes" avant d'attaquer les "choses sérieuses". Commencer par du procédural comme C c'est parfait, les étudiants comprennent facilement la logique et arrivent à résoudre par eux-même de petits problèmes (en tous cas ceux qui ont un tant soit peu d'esprit logique).Citation:
Envoyé par metagoto
1 - Totalement d'accord avec toi.Citation:
Envoyé par JolyLoic
3 - Je dirais qu'il faut utiliser se dont on a besoin... et pas hésiter à refaire des classes stl minimalist si cela correspond plus à nos besoin.
2 - Absolument pas d'accord. Même si je reconnais qu'il faille couper les ponts à un moments, j'ai vue trop de code "java like" avec ce type d'approche. Et le code C++ d'horreur et à mon avis pire que le "C with class".
Comprendre ce que la pile, le tas, les allocations dynamiques enfin bref, la couche C commune au C++, c'est évité des absurdités immondes, des habitudes que l'on crois bien, et qui s'incruste.
Et je pense qu'il est bien plus facile de prendre du C++ java pour une bonne habitude que du C with Class...
La faute en incombe peut-être au fameux "hello world", du moins en mode OO.Citation:
Envoyé par Lavock
Intéressant, mais quid de l'histoire du langage, de ses ancêtres (ceux dont il dérive) et de sa raison d'être (incluant son domaine d'application) ? Puis-je envoyer un email à son créateur, est-il inscrit sur twitter ? :mrgreen:Citation:
Envoyé par koala01
Non, vraiment, je pense que négliger cette étude historique et fonctionnelle est une erreur.
@Cheps
Je pense que python est un langage sérieux. Neophite-friendly, oui, mais tout à fait adéquat pour sérieusement aborder la programmation.
Pas en première approche...Citation:
Envoyé par metagoto
En première approche, ce qui t'intéressera vraiment, c'est de savoir comment tu pourra faire ce que tu veux avec le langage que tu a devant les yeux, et s'il est adapté à tes besoins.
Par exemple: je connais Cobol, mais je ne l'utilise pas pour l'instant, vu que je n'en ai pas l'intérêt (il faut dire que, actuellement, c'est plutôt un langage de niche).
Je sais qu'il a été créé à une époque où les programmes tenaient encore sur des petits morceaux de cartons perforés, et je sais dans quels domaines je risque encore bien de le rencontrer à l'heure actuelle.
Mais, en dehors des éléments que j'ai cités plus haut, ai-je vraiment par besoin de savoir qui il a été écrit, comment et dans quel but :question:
Est-ce que ces informations feraient de moi un meilleur programmeur Cobol :question:
Appliqué au C++: Est-ce que le fait de pouvoir contacter stroutroup, alexandrescu ou n'importe quel guru ou membre du comité de standardisation fait de moi un meilleur programmeur C++ :question:
Faut il absolument avoir l'adresse électronique de Linus Tovald ou de Bill Gates dans sa liste de contacts pour être en mesure d'utiliser correctement linux ou windows :question: Faut-il seulement connaitre leurs noms :question: (tu me dira, il est difficile d'avoir la moindre discussion sur le sujet sans que ces noms n'apparaissent, ou peu s'en faut ;))
Au niveau des ancêtres, c'est presque encore pire: c'est parce que le C est l'ancêtre le plus direct du C++ que l'on en arrive à se dire que C++ n'est qu'une "surcouche" de C et à apprendre en réalité du C with class...
A l'extrême limite, je dirais presque que, avant de savoir d'où vient le langage, ce qui m'importe bien plus, c'est de savoir sur quelles plateformes il est disponible et si la licence d'utilisation est compatible avec celle que j'en aurai.
Au final, l'historique ou les "grands noms" des gens qui l'ont développés ou qui ont apporté une contribution au langage vient par la suite, et tu n'en a, à peu de chose près, strictement que faire lorsqu'il s'agit de "faire tourner" ton premier programme dans un langage que tu découvres ;)
Et pourtant, le C++ n'a pas été conçu dans ce sens, si je ne m'abuse.Citation:
Envoyé par koala01
Bien sur que C++ n'a pas été conçu dans ce sens...Citation:
Envoyé par maxim_um
Mais, il n'empêche que le gros problème que l'on rencontre, et qui est, finalement noeud de la discussion ici présente, c'est que trop souvent le C++ est appris comme tel (comme du "C évolué", s'entend), pour la simple raison que C++ a veillé à assurer une certaine compatibilité avec C et qu'il en partage la syntaxe.
Mais, dans l'absolu, ce problème pourrait très bien apparaitre avec n'importe quel langage dont on pourrait dire "il descent de tel autre", qui en respecte la même syntaxe et qui veille à assurer une compatibilité ne serait-ce que partielle avec son "ancêtre" ;)
Et c'est pour cela que, bien qu'il ne soit absolument pas question (du moins dans mon chef) de renier les origines du C++, je plaide pour que l'on n'approche ses similitudes avec C que le plus tard possible, lorsque ce que l'on considère généralement comme les "bonne habitudes" propres au C++ auront été correctement prises.
Si on travaille dans l'autre sens (ce qui est trop souvent vrai), nous obtenons des programmeurs fortement ancrés dans des habitudes issues du langage ancêtre (le C, en l'occurrence) et qui auront du mal (même si c'est relatif) à s'en débarasser pour acquérir les habitudes propres au C++.
Il me semble toujours préférable d'apprendre la règle de base avant de vouloir appendre l'exception.
Bien sur, l'exception à une règle est tout aussi importante (et parfois plus) que la règle générale, mais... elle doit rester une exception ;)
Dans le cas qui nous occupe, la règle générale, c'est de manipuler la S(T)L tant qu'on peut, et, lorsque l'on n'a pas le choix (pour des raisons pouvant être multiples et variées), se tourner vers les solutions issues du C (pointeurs et gestion dynamique de la mémoire "à la main" en tête de liste)
C'est le problème des réflexes (conditionnés), le souci, c'est qu'il est très difficile de s'en débarrasser.Citation:
Envoyé par koala01
Mais pourquoi ressens-tu une gêne à dire SL au lieu de STL, ou plutôt quelque chose qui a l'air de vouloir concilier les deux, comme avec le C et le C++ ?
Pour savoir ça, il faut avoir étudié un minimum les généralités sur ce langage justement.Citation:
Envoyé par koala01
Ma question est a placer dans un contexte "professionnel": la personne a une expérience avec au moins un langage. Étudier l'historique (ce qui peut être fait en quelques minutes, je ne dis pas qu'il faut faire une thèse à ce sujet) permet de dégager à la fois les grandes lignes communes avec le langage qu'on connait déjà (ou les langages) et surtout les différences. Ensuite quand on plonge dans la grammaire, la sémantique, le comportement au runtime et tout le reste, on va beaucoup mieux percuter sur ce qui est important: ce qu'on ne connait pas déjà.
:ccool: Mon clin d'oeil pour l'email de l'auteur.. c'était un clin d'oeil justement (bien que je trouve fascinant la proximité contemporaine avec les créateurs des langages usuels). On ne peut pas dire ça de la musique ou des mathématiques!Citation:
Envoyé par koala01
Là je ne suis pas d'accord. Certes, on peut ignorer tout ça et y aller quand même, mais c'est du temps de perdu. Par exemple, les shells unix (bash, sh etc) : on va beaucoup mieux capter la syntaxe bizarre et les règles de scoping bizarres également si on sait que à la base c'est un interpréteur de lignes stand alone et que, par exemple, /bin/[ est un executable. L'individu est tout de suite mieux conditionné pour progresser dans l'apprentissage.Citation:
Envoyé par koala01
C'est parce que je fais un distingo clair entre ce qui fait partie de la STL et ce qui fait partie de la SL...Citation:
Envoyé par maxim_um
Même si, de fait, la STL est en réalité un sous ensemble de la SL ;)
Je ne dis pas que ce n'est pas intéressant à connaitre, je dis que, si tu tombe sur un patron ou sur un client qui te dit "je veux que vous me codiez mon application en <rajouter ici un langage quelconque>" tu n'a pas forcément besoin de savoir tout cela pour autre chose que "ta culture générale".Citation:
Envoyé par metagoto
Si, par la suite, tu "accroche" avec le langage en question, tu pourra effectivement t'y intéresser d'avantage, mais, si tu t'y intéresse dés le début et que tu te dépêchera d'oublier ce langage parce que c'est "vraiment pas ton style", t'aura (au moins l'impression d'avoir) perdu énormément de temps pour rien ;)
De même, je ne dis pas qu'il ne faut pas connaitre les possibilités du C pour apprendre le C++, mais je dis qu'il ne faut les utiliser que lorsque l'on n'a absolument pas d'autres choix.
Et je dis que l'accent prioritaire de l'apprentissage doit être mis sur les capacités propres au langage réellement utilisé, et non sur les capacités des langages ancêtres.
S'il y a effectivement un intérêt à connaitre l'ancêtre pour se faciliter la tache avec le descendant, il est effectivement peut être de s'intéresser à l'ancêtre en priorité (comme pour les shell unixoides).
Mais ce n'est absolument pas le cas entre C et C++ (qui représentent quand même le centre du débat actuel) qui, au final, ne font "que" partager une syntaxe commune, et finalement pas si compliquée ;)
Par curiosité, je suis allé voir les bouquins de C++ qui sont mis à notre disposition à la BU (bibliothèque universitaire). Comme dans la quasi totalité des étagères, on y trouve en majorité des livres plutôt anciens (jusqu'a un peu avant 1990 pour celle-ci).
J'ai été surpris de voir que, sur les 3 ou 4 que j'ai ouvert, un seul parlait de std::string et std::vector (il datait de 2008 tout de même...).
Pour les autres : dans les premiers chapitres, c'est du C où printf est remplacé par cout. Puis ils abordent les classes, l'héritage, et enfin les flux.
A noter que, dans le bouquin le plus récent, les exceptions étaient placées en annexe, avec les templates (ces deux sujets sont, bien sûr, totalement absent dans les autres livres).
Du coup j'ai fais quelques recherche, et je me suis rendu compte que le C++ tel qu'on le pratique de nos jours est en fait très récent : d'après Wikipedia, la STL a été acceptée dans le standard en 1994 (et j'ai lu sur ces forums que les premières implémentations étaient tout sauf parfaites).
Quand on connait le temps que met l'enseignement (du moins en physique, de ce que je peux juger) pour tenir compte des dernières avancées, on comprend mieux la situation.
Enfin, ça c'est pour les plus jeunes comme moi, qui n'avons pas connu le C++ d'avant 2003 ;)
Ca fait quand même 15 ans déjà! Il y a des anecdotes à propos de Stepanov et Lee demandant sans cesse à Stroustrup et Koenig si telle ou telle portion de STL "compilerait" car à l'époque à la fois les propriétés du langage nécessaires et les compilos, de surcroit, n'existaient pas ou n'étaient pas fixées. Rétrospectivement, c'est assez miraculeux que ça ait fonctionné :ccool:Citation:
Envoyé par Kalith
Pour rebondir sur la (sous) discussion avec koala01 et l'intérêt, à mon sens, de s'intéresser le plus tôt possible à l'aspect historique et philosophique d'un langage quelconque que l'on souhaiterait apprendre, est un Dr Dobb's "Productivity Award" decerné dès 1995 à The Design and Evolution of C++ (ok, avec Dr. Dobb's, c'est un tantinet biaisé :mrgreen:). Un DNE en parallèle d'un AC++ pour commencer, moi je dis, y aura du boulot de fait :ccool:
Bonjour à tous,
Je reviens un peu sur le problème de l’apprentissage du C/C++, notamment sur l’idée d’apprendre les deux en même temps. Et bien pour avoir appris en même temps le C et C++, je ne conseille ça à personne. Je ne vous dis pas la perte de temps à passer de l’un à l’autre, à hésiter entre tel et tel manière de résoudre mon problème, à se documenter sur les deux langages en même temps… Autant vous dire que j’aurais préférer directement commencer par le C++. L’idée même d’apprendre deux langages en même temps (si on considère le C et le C++ comme parfaitement distincts) me semble un brin foireuse : vous auriez aimé commencer la prog avec un mélange de COBOL et de Java vous ?
Pour moi il ne fait aucun doute que débuter la programmation avec le C++ est une très bonne idée, à deux conditions : avoir préalablement suivi un cours d’algorithmique (on saura plus facilement quel algo de la STL utiliser dans tel cas ou quand implémenter nos propres solutions, quel conteneur privilégier en fonction de la situation, etc.), et suivre une petite formation sur les pointeurs (parce que c’est quand même à la base de tout). On est ensuite paré à tout ce qui va nous tomber sur le coin du crane, et on peut commencer le C++ par n’importe quel bout. A mon sens, entamer la programmation par le C++ offre pas mal d’avantages :
- On se prend une bonne claque au début, c’est sur. Les moins motivés iront voir ailleurs, ca évitera justement les joyeux mixeurs de C/C++ qui donnent une si bonne réputation au C++ dans les entreprises.
- Un développeur qui ne pratique qu’un langage ne va pas loin. Mais une fois maitrisé le C++, on apprend les autres langages en chantant et en dansant.
- Une fois à peu prés maitrisé le C++, il est plus facile de présenter le C : « le C est un langage ayant la même syntaxe que le C++ (une chance pour vous) mais vous ne pouvez pas utiliser ca, et ca, et re-ca, l’allocation/deallocation de mémoire se fait de cette manière étrange, les entrées/sorties de cette manière plus étrange encore, et j’en passe et des meilleurs ».
Un avis que ne partage pas tout le monde, mais j'aurais aimer qu'on me présente les choses de cette manière dans mon cursus ;)
Pour avoir appris différents langages sur une période à peine plus grande qu'un mouchoir de poche, je n'ai pas d'objection à ce que les gens en apprennent plusieurs, à une condition sine qua non: que chaque langage soit appris indépendamment des autres, dans l'idée, et dans la pratique.Citation:
Envoyé par vikki
Je veux dire par là: en C, on apprend le C, en C++, on apprend le C++, en java, on apprend java et en Cobol on apprend Cobol... Et on ne parle que de cela.
Bien sur, si tu sors de deux heures de cours sur C et que tu passe, dans la classe d'à coté, pour deux heures de C++ ou de cobol, effectivement, tu risque de perdre un bon quart d'heure avant de recommencer à penser non plus en C mais bien en C++ ou en Cobol...
Mais, à coté de cela, ce genre d'horaire aurait presque l'énorme avantage d'aiguiser l'esprit d'adaptation, qui, à mon sens, prend aussi une bonne place dans la conception et la programmation.
Je suis le premier à plaider pour une connaissance théorique minimale adaptée (il ne sert pas à grand chose de connaitre la théorie OO pour programmer en séquentiel, et la connaissance de la seule théorie séquentielle est un peu limite lorsqu'il s'agit de programmer OO) lorsque l'on entame l'apprentissage d'un langage, mais il ne faut pas oublier non plus que la conception et la programmation sont des arts, car nous sommes toujours face à l'obligation de de nous adapter selon les circonstances.