Ce n'est pas tant aux affaires de portée que je pensais, mais au polymorphisme des itérateurs associés aux algorithmes. Les histoires de traits, de bidirectional_iterator etc.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ce n'est pas tant aux affaires de portée que je pensais, mais au polymorphisme des itérateurs associés aux algorithmes. Les histoires de traits, de bidirectional_iterator etc.
SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.
"Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
Apparently everyone. -- Raymond Chen.
Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.
Mais qu'est-ce qui t'empêche d'apprendre à gérer la mémoire dynamiquement en C++Envoyé par Ksempac
Déjà, comme je viens de l'expliquer, c'est un problème qui peut être abordé "plus tard" en C++, alors que c'est un des premiers problèmes qu'il faille aborder en C (on est très vite limité par l'usage des seuls tableaux statiques en C, et, dés qu'il s'agit de les passer à des fonctions, il faut... passer par les pointeurs)
Ensuite, new et delete font malgré tout beaucoup plus que ce que font respectivement m/re/c alloc() et free()
Enfin, on n'utilise même pas les mêmes termes (sauf cas particulier du placement new)
Dés lors, pourquoi faudrait il faire entrer la connaissance de ces techniques C dans la liste des prérequis pour le C++
A méditer: La solution la plus simple est toujours la moins compliquée
Et même là, à la limite, je ne vois toujours pas d'objection à "remettre à plus tard" (comprend: à un moment où les connaissances orthogonales de l'étudiant seront suffisantes pour comprendre le principe) l'étude du "comment cela fonctionne"...
En tenant compte du fait que les délais d'apprentissage sont souvent limités et que l'on risque de manquer de temps pour aborder ce point de vue particulier, rien n'empêche celui qui veut réellement se "spécialiser" en C++ après son apprentissage de s'y intéresser par lui-même (il y sera de toutes manières mené tôt ou tard)
Je suis d'accord, et c'est ce qui me fait hésiter sur la question originale...
A l'origine, l'objet était une solution à certains problèmes des langages classiques. Il permettait de faire bien mieux des choses réputées très difficiles (on peut dire la même chose de tous les paradigmes, soit dit en passant).
Aujourd'hui, sous l'influence de Java et de l'enseignement "pur C++", on voit arriver des programmeurs qui n'ont fait presque que de l'objet, avec des tartines de design pattern autour. Sur pas mal de problèmes réels (par exemple, toutes les activités, assez linéaires, de traitement de données, ou de calcul pur), ils souffrent enormément, là où un peu de connaissance du "procédural" aiderait grandement. A mon avis, il est très utile d'apprendre en même temps le procédural et l'OO.
Et c'est là que le C est utile. Comme il partage pas mal de syntaxe avec le C++, le surcout d'apprentissage est faible.
Au total, je pense qu'il faut les apprendre en même temps, mais différemment, ie pas de façon "compétitive". (genre : en C on faisait malloc et on utilisait des tableaux de char, en C++ la bonne pratique...).
Ou alors, il faudrait enseigner davantage les possibilités procédurales du C++ (et là, on est loin du compte, mis à part d'Accelerated C++, qui est décidement une perle!).
Francois
Il est clair que l'influence des langages "tout objet" (ou du moins "exclusivement OO") a eu quelque chose de néfaste dans les méthodes d'apprentissage, et ce d'autant plus que beaucoup de monde a eu tendance à considérer l'OO comme "la solution ultime à tous les problèmes".
Une autre influence négative vient sans doute du fait qu'il n'existe que peu d'écoles de pensées pour lesquelles les techniques de conception (algorithmie, étude de l'OO en tant que méthode de conception, ...) sont indépendantes d'un langage particulier.
Trop souvent, on apprend l'algorithmie ou l' OO durant l'apprentissage d'un langage donné, parce que "ce sont des notions qui deviennent nécessaires" pour aller plus loin.
De ce fait, on en arrive à avoir une approche de l'algorithmie ou de l'OO qui est biaisée par les propres limites du langage.
Les exemples de ce que j'essaye de faire passer sont légions:
Les javaistes ne connaissent l'héritage multiple que de nom et le considère comme une pratique quasi satanique, quand ils ont déjà conscience (pour les débutant) de la virtualité systématique des fonctions membres qu'ils écrivent
Les principes de base de l'OO comme LSP ou Demeter ne sont quasiment jamais abordés, et seuls ceux qui "en auront entendu parler par ailleurs" s'y intéresseront plus ou moins ( et décideront de veiller à les respecter... ou non)
La définition même de l'Orienté Objet donnée par de nombreux "débutants" (comprenez: par les gens qui apprennent leur premier langage OO) est souvent tronquée et tourne généralement autour d'un certain type de polymorphisme et de la présence de fonctions membres.
Or, si l'on a une approche beaucoup plus globale du problème, on se rend compte qu'une boucle ou un test reste une boucle ou un test et qu'une fonction reste une fonction, quel que soit le langage envisagé et cela, même si c'est une fonction membre ou une fonction "de classe" (AKA statique
Les seules différences réelles tenant, en définitive, dans la manière dont il faut traduire ces concepts pour que le langage les comprenne...
Une fois que l'on a pris conscience de tout cela, rien n'empêche d'apprendre l'algorithmie ou la conception OO sans faire référence au moindre langage de programmation existant (bon, cela peut devenir lassant pour l'étudiant de ne pas pouvoir tester son algorithme ou sa conception
Puis, une fois l'algorithmie et l'approche purement séquentielle terminée, faire pareil avec l'OO, en entrant enfin dans le vif du sujet...Nous avons vu les fonctions en algorithmie, voici comment on fait en C++, et voici la fonction principale que l'on appelle main
<...>
Nous avons vu les différentes boucles / les différents tests en algorithmie, voici comment on les traduit
<...>
Nous avons vu les différents types de collections possibles, voici ce que C++ fournit (std::vector std::list,...) et voici comment on les emploie (foutons nous royalement, dans un premier temps du "comment ca fonctionne en interne")
<...>
Nous avons vu en algorithmie qu'il est possible de créer des structures afin de regrouper des informations, voici comment on fait en C++ (utilisation de struct et union, principalement)
Si on inverse l'ordre d'apprentissage de manière à ce que les principes généraux soit appris avant la manière particulière de les implémenter dans un langage donné, il est tout à fait possible de ne demander comme pré requis indispensable que de... savoir utiliser le clavier... ou un analyseur vocal réellement efficace... quitte à indiquer que telle méthode particulière est déconseillée ou interdite pour un langage particulier (comme c'est le cas pour l'héritage multiple en java)
[EDIT]J'en ai oublié ma conclusion principale:
Il "va de soi" que, lorsque l'on apprend un langage "mono paradigme", on ne va, fatalement, s'intéresser qu'aux techniques proposées par ce paradigme en particulier:
Les principes OO n'auraient rien à faire dans l'apprentissage de C, et avoir une approche autre que purement OO en java n'aurait aucun sens...
Mais C++ étant un langage multi paradigmes, apprenons aux gens à utiliser correctement chacun d'eux, et l'ordre logique pour se faire est d'apprendre en priorité le paradigme le plus simple.
Commençons donc l'apprentissage de C++ par une approche purement procédurale (après avoir assimilé, comme je l'ai indiqué plus haut, les concepts généraux applicables à ce paradigme particulier), puis augmentons progressivement la difficulté en passant par une approche OO avant d'attaquer l'approche générique...
Je suis conscient que dans le cadre d'un apprentissage scolaire, nous risquons réellement de manquer de temps pour tout voir en profondeur, mais, si l'étudiant a déjà une compréhension correcte et suffisante des deux premiers et que l'on n'a malheureusement pas pu faire autre chose que de "gratter la surface" de l'approche générique, nous aurons déjà quelqu'un d'assez calé dans le langage à la fin de son apprentissage
[/EDIT]
C'est pour cela que je préfère toujours comparer avec un excellent langage qui est en plus reconnu pour ses qualités pédagogiques : l'Ada. La gestion de la mémoire y existe, et elle y est manuelle. Et pourtant dans un cours d'Ada, c'est vu vers la fin. Pour voir ce qui est fondamental d'abord : l'algorithmique.
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
C'est globalement pour ça que je milite. La plupart des gens qui recommandent de passer par le C recommandent en fait de passer par du procédural.
Je suis pour commencer par du procédural, mais pour le faire en C++. C'est ce que je fais dans mes cours.
Et si ce procédural utilise sous le chapeau des objets, sans que l'étudiant crée les siens directement, ce n'est pas grave, et ça n'a dérangé personne d'apprendre d'afficher en faisant cout <<, pour plus tard apprendre qu'en fait cout fait partie d'une hiérarchie et que si on passe un ostream& à une fonction elle pourra afficher sur l'écran ou écrire dans un fichier.
L'avantage est que ce procédural en C++ a une courbe d'apprentissage bien plus douce que le procédural en C.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
pourriez-vous définir les termes : STL, approche descendante et montante svp ?
STL : F.A.Q. Qu'est-ce que la STL ?
Approche descendante : partir de concept plus abstraits vers des mises en œuvres plus concrètes.
Approche montante : à partir d'approche plus concrète voir comment elles peuvent gagner par l'abstraction.
J'ai pour ma part trouvé une évidence dans l'approche procédurale. Je l'ai ressenti comme une transposition directe de l'enseignement mathématique reçu au collège ou au lycée : une démonstration ou un exercice est résolu en étapes successives découpant le problème de son énoncé vers sa solution en une séquence d'"instructions". L'approche procédurale en informatique suit une démarche similaire de séquencement du problème en étapes déroulées les unes à la suite des autres. J'ai ressenti l'approche objet de façon plus intuitive avec le 'réel' - à condition de faire la démarche d'abstraction.
En revanche, je pense qu'une base de structures de données et algorithmes est aussi nécessaire.
Ressources proposées par 3DArchi - Les fonctions virtuelles en C++ - Cours et tutoriels C++ - FAQ C++ - Forum C++.
ou, de manière générale, de n'importe quelle procédure nécessitant un ordre précis et particulier d'actions à entreprendre.
Je fais souvent le parallèle entre deux situations qui poussent au cocasse: le fait de changer une roue et une recette de cuisine.
Tout le monde s'attend en effet à avoir des problèmes sans nom si, pour changer sa roue, il retire les boulons avant d'avoir placé et élevé le crick...
Et personne n'oserait envisager d'inclure les oeufs dans une pâte à crepes après... avoir cuit la pâte.
L'algorithmie, ce n'est, en définitive que la tentative de trouver la logique la moins mauvaise possible (à défaut d'être la meilleure
Et, même dans une approche orientée objet, il faut pouvoir respecter l'ordre logique envisagé, voire, parfois, être en mesure de ne pas considérer un objet du point de vue des services qu'il peut rendre, mais bel et bien du point de vue de son utilité dans la situation dans laquelle on se trouve (en essayant cependant de ne pas trop le détourner de son utilisation naturelle)
Oui, mais tu peux avoir cela avec d'autres paradigmes. Là où il me semble que l'approche procédurale est intuitive, c'est qu'elle consiste essentiellement en une suite d'actions (de "verbes" si tu veux), qu'on applique à des données, linéairement ou pas (ce n'est pas toujours linéaire ni successif, sans structures de controle, on ne va pas bien loin).
Cette séparation des données et traitements est très naturelle, parce que c'est comme ca qu'on abord les problèmes qu'on définit comme des processus.
Je ne suis pas tout à fait certain que les maths soient le meilleur exemple, en maths justement, la notion d'objet, et de propriétés liées à ces objets, est extrèmement importante ("cette fonction est continue, et l'ensemble que l'on considère est ouvert, ou fermé, ou compact, donc...")
L'objet, c'est différent, parce que justement, ca insiste davantage sur la description des "choses" et de leurs propriétés que sur les processus et les recettes.
Mon impression, c'est que ca marche bien quand il n'y a pas besoin d'abstraire... Avec de "vrais objets" comme la souris, les fenêtres, les boutons, les fichiers, l'objet marche bien, parce que c'est une façon naturelle de décrire le monde. Pour tout ce qui est simulation, c'est idéal.
Là où ca tourne souvent mal, c'est quand justement, il faut abstraire, parce que les "objets", les classes, ne sont pas faciles à voir... On peut bien sur s'en sortir, avoir une superbe intuition, et faire du code objet sublime, mais alors, il est à peu près certain que le développeur qui suivra ne comprendra rien à notre trait de génie...
Mais typiquement, dans ces situations où l'objet n'est pas une évidence, où les "données" ou les concepts de base ne sont pas clairs, il est souvent facile de "penser processus" et le procédural marche bien...
D'où l'intérêt d'apprendre les deux...
(En ce qui concerne le générique, je ne crois pas qu'il s'agisse d'un paradigme aussi fondamental que l'objet ou le procédural, en fait c'est plutôt une "astuce", qui permet faire, tant bien que mal, coexister les deux)
Je ne suis pas trop d'accord avec cela. L'algorithmique, pour moi, c'est un savoir faire très informatique, qui consiste à bricoler un traitement pour le rendre plus rapide (généralement, plus scalable). Ce n'est pas réellement logique, c'est plutot une série de recettes (diviser pour régner, ce genre choses). Et d'ailleurs, les algos performants sont rarement intuitifs (regarde Quicksort, ou la Transformée de Fourier Rapide...)
Francois
C'est marrant ça, plus ça va et plus je rejoins cette idée que certains émettent, que commencer par un langage fonctionnelle c'est ce qu'il y'a de plus *aisé* et efficace.
Remarque que d'autres m'objecteront que c'est parce que j'ai été nourri au biberon avec des maths ...
De nos jours c'est pas tout à fait vrai , c'est bien plus qu'une simple astuce.
"Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu
Je ne sais pas si c'est simple, ou plutôt, il faut une tournure d'esprit assez particulière pour trouver ça simple. Mais si on cherche l'élégance en informatique, les langages fonctionnels (surtout les plus dépouillés d'entre eux), ça vaut le détour.
Aussi, comme l'objet par rapport au procédural, ca apporte un regard vraiment nouveau sur des choses qu'on croit bien connaitre...
Mais bon, ca reste un peu dangereux, le fonctionnel, une fois qu'on y a gouté, on aime moins les autres langages...
Si t'aimes l'informatique et les maths, faut faire du J, Goten (ou de l'APL). C'est beau à pleurer, le J...Remarque que d'autres m'objecteront que c'est parce que j'ai été nourri au biberon avec des maths ...
TU as raison, "astuce" n'est pas le bon mot. Ce que je cherchais à dire, c'est que si procédural, objet, fonctionnel (ou tacite dans le cas de l'APL/J), ce sont des paradigmes qui impliquent un point de vue sur les choses, une façon particulière de penser ses programmes, la programmation générique, ca relève davantage de la technique pure (un peu comme les choix en matière de typage). Il y a une façon procédurale, objet, fonctionnelle, tacite, d'aborder un problème. je ne crois pas qu'il y ait une façon "générique".
Francois
Dernière modification par Invité ; 05/03/2010 à 21h55.
Ah oui tout à fait je vois ce que tu veux, dire je suis tout à fait d'accord. Je me suis sentis obligé de relever ayant en tête ce que ces derniers temps la généricité apporte au monde du C++. (MP, traits et policies etc).
Quand au J j'avoue ne pas connaitre (même pas de nom, c'est pour dire). Pour l'instant niveau FP je me borne au haskell et au template du C++, mais je vais y jeter un coup d'oeil.
ps : pardon pour la grosse digression ..
"Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu
Avant, après ou pendant ... des connaissances en C seront quant même utiles pour aller plus loin dans l'apprentissage C++.
Donc je peux commencer à apprendre le C++ comme nouveau langage sans problème avec mes acquis.
Je ne pensais pas faire un tel debat !
des avis sur un livre
Je compte alors me prendre le livre Apprendre le C++ de Claude Delannoy, qui dispense un enseignement non historique.
Je pourrais tout à fait apprendre le C++ depuis mes bases de programation acquises sous vb.net.
Mais ce livre n'est peut etre pas assez basé sur une programmation procédurale. Comme j'ai pu lire de nombreux reproches sur le fait qu'il est important de ne pas faire que de la POO.
J'ai parcouru plusieurs Delannoy sur le C++, et à chaque fois j'étais effaré de ce que j'y ai lu. Donc, à moins qu'il se soit amélioré récemment, je conseillerais fortement d'éviter.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Au contraire. Il est complètement historique dans son approche : la bibliothèque standard est relégué au statut d'annexe, et les pointeurs sont vu dès les premières chapitres, tout comme les tableaux statiques et dynamiques, et autres char*.
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
Les anciens bouquins "Programmer en C++" avaient une approche historique mais pas le dernier "apprendre en C++", en tout cas c'est bien ce que j'ai vu dans la fiche du livre sur le site.
Je dois avouer que ce qui me tente aussi dans ce livre est l'édition de poche qui n'est qu'à 20€ au lieu des 35€ habituel d'un livre informatique. La différence de prix n'est pas négligeable dans le porte-monnaie d'un étudiant !
Regarde l'ordre des chapitres. C'est du pur historique.
Compare avec l'ordre des chapitres d'AC++ ou du dernier Stroustrup.
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager