Je comprends totalement ton point de vue gbdivers, tellement bien que je suis en désaccord avec toi.
J'ai commencé à programmer en C++ vers 14 15 ans pcq je voulais programmer des jeux vidéos.
En réalité, je me suis contenter (pcq j'ai jamais voulu allé plus loin à ce moment là) de programmer des choses simples de temps en temps pour le plaisir, du genre coder les nombres premiers, faire des statistiques dessus etc. Je codais sur un seul fichier, parfois presque tout dans la fonction main, ça dépassait jamais les 300 lignes de code ; et j'ai jamais poussé plus loin, sinon j'aurais passé plus de temps par ex sur le deuxième chapitre d'openclassroom qui initie aux classes / pointeurs
Enfin bref, de tout ce que tu as dis je pense le contraire tu défends tes idées avec des postulats qui sont les contraire des miens, ton analyse n'en reste pas moins cohérente je ne me fis juste qu'à mon expérience et partage mon point de vue sur les sujets évoqués, dans un contexte plus général
Après je te le dis très honnêtement, ton cours est très bien agencé, juste qu'il n'est pas orienté pour un autre public, dont j'ai fais partie, et ne le sert pas pour autant comme tu sembles le dire (c'est plutôt là où est mon désaccord). En gros si je fais du C++ aujourd'hui c'est grâce à openclassroom dans un premier temps, et bien évidemment il est TRES incomplet pour la suite et probablement même je le reconnais pas optimal / parfait non plus, disons qu'il fait l'affaire pour un débutant quoi, pour ses débuts (et il ne va pas accumuler de lacunes).
je suis arriver au chapitre de la SQL en C, sur le site, mais vu que un bon nombre de personnes veulent une refonte du cours car il est trop "vieux", j'ai voulu "changer" un peut, je voudrais faire de la programmation embarquée, donc arduino par exemple, créer des IA, pourquoi pas quelques jeux... Enfin, pour le moment, je n'ai aussi que 15 ans et donc le professionnalisme n'est pas ma priorités pour le moment. Mais j'ai rencontrer plusieurs personnes relatant que que c'était contre éducatif d'apprendre le C++ après le C... Donc je sais pas trop quoi en pensé... Sinon, j'ai appris le python, le cours de Céline Martinez Sanchez, je pense, mais python ne me dit rien, il ne m'attire pas trop, même si c'est un langage fonctionnant sur les principes du C et C++
Mais je n'ais pas vraiment compris ce que tu voulais dire par là :
C'est probablement un point qui justifie d'orienter les personnes vers un autre langage que le C++ : beaucoup ont des fausses idées sur le C++. En particulier "le C++ est plus performant" et "le C++ est plus adapté pour les jeux vidéos".
Le C++ reste un très bon langage, mais ce n'est pas non plus "LE" langage universel parfait, et son apprentissage demande un certain investissement.
sinon, merci je vais jeter un oeil sur vos liens
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
qu'il n'est pas orienté pour un autre public, dont j'ai fais partie
J'ai toujours dit que mon cours s'adresse à un public différent du cours d'OCR. (Mais c'est une chose que je vais probablement un peu corriger, mais pas trop).
Et sans plus d'information sur ton utilisation du C++, j'ai l'impression que tu fais parti de ceux qui ont appris et utilisent le C++ pour de mauvaises raisons. Très clairement, je préfère orienter ce type de profil vers le cours de Python de Swinnen plutot que le cours C++ d'OCR (ou plutot que d'adapter mon cours a ce type de profil)
vanaur a écrit:
je voudrais faire de la programmation embarquée, donc arduino par exemple,
Mais je n'ais pas vraiment compris ce que tu voulais dire par là
Le C++ (et le C et le Java et le C# et le...) est un langage historique, donc beaucoup d'idées dessus ne sont plus d'actualité. Les langages evoluent.
Quand on veut faire des jeux, on utilise en priorité un moteur de jeux. C'est déjà plusieurs années de boulot. La programmation n'est qu'un des outils utilisés en jeux vidéos, pas une base nécessaire et indispensable pour commencer.
Pour les performances, le C++ n'est pas plus performant que les autres langages. Il permet d'accéder à plus de performance, mais cela a un coût (apprentissage, temps de developpement, maintenance, etc). Si on n'est pas prêt a investire les années de formation nécessaire pour aborder ces fonctionnalites, alors utiliser le C++ n'apportera pas un avantage significatif par rapport aux autres langages.
Perso je trouve que le C++ propose suffisamment d'outils bas niveau pour faire qqch de très précis d'un point de vue matériel, et à la fois permettre au code d'atteindre une formalisation haut niveau. La portée du C++ en terme de formalisation est elle aussi banale que ça par rapport aux autres langages ??
Je veux bien croire qu'un professionnel d'un langage peut rivaliser avec un professionnel du C++, mais j'en reviens à la formalisation : le C++ n'est-il pas un des meilleurs langages pour ça ?
Je ne suis pas très expérimenté, mais quand je vois de l'ada, du C, du php, du python, ou même du C# et java (bcp de dérivés du C là dedans), franchement j'ai envie de rester dans mon C++. De plus il est dit et je pense que c'est en grande partie vrai que si l'on connaît le C++ et tous les concepts qui l'entoure, on peut très facilement comprendre et manipuler correctement d'autres langages, ou encore apprendre plus facilement de nouveaux concepts de programmation
Et sans plus d'information sur ton utilisation du C++, j'ai l'impression que tu fais parti de ceux qui ont appris et utilisent le C++ pour de mauvaises raisons
C'est normal, j'ai toujours été attaché à bien programmer avant de faire un projet énorme, je n'ai donc pas encore beaucoup de projets à mon actif, donc l'utilisation que je fais du C++ reste encore très légère aujourd'hui. De nature je n'aime pas faire qqch s'il n'est pas opti. Très récemment j'ai fais un analyseur générique LL + définition intuitive d'un langage, ainsi qu'un projet générique sur la formalisation d'un problème de logique et résolution SAT (avec un vrai travail sur la formalisation du code et différentes optimisations personnelles). Cet été je vais aborder les bases de l'ECS, et je vais sans aucun doute m'appuyer sur ton cours où tu l'abordes.
Je sais pas si j'utilises le C++ à de bonnes fins (si je dois programmer hors net j'utilise le C++ en tout cas), mais j'ai le sentiment de pouvoir tout faire avec ce langage, j'ai plus de doutes quant à d'autres langages, du moins sur une formalisation haut niveau d'un problème tout en soignant les performances bas niveau. Et si j'ai commencé par le C++, c'est effectivement pcq on m'avait dit qu'il était très utilisé dans le domaine du jeu vidéo. J'dis pas que le langage est fait pour ça, mais encore une fois je pense que c'est pour les raisons du dessus, du moins en partie. Peut-être que je me trompe
Le C++ ne rend pas automatiquement le code plus rapide. Il donne des outils aux experts pour rendre le code quasiment aussi rapide que possible, mais ça ne veut pas dire que ça se passe tout seul, on peut très facilement écrire du C++ lent. Et la contrepartie, c'est un langage dont la moitié devrait disparaître immédiatement si il ne fallait pas être rétrocompatible, et qui te punira d'un crash random chez tes clients à la moindre erreur.
C'est encore un langage fondamental dans l'industrie, mais beaucoup trop de gens s'imaginent que c'est le langage qu'ils doivent forcément utiliser. Tu peux regarder Rust ou C# par exemple, ou des choses plus haut niveau - C# par exemple c'est le langage phare du jeu vidéo depuis Unity3D.
Ecrire un cours de C++ en partant du principe que les lecteurs sont patients et ne cherchent pas à avoir un truc flashy tout de suite, c'est juste du bon sens.
C++ est un outil, dés l'instant où on perd cela de vue, on dit vite n'importe quoi. Utiliser un tournevis pour planter un clou est certes possible, mais il faut bien admettre que le marteau est plus adapté. Si on me met au volant de la meilleure F1 du championnat, est ce que je serais le prochain champion du monde de F1? Probablement pas. Pour rester dans la métaphore automobile, un célèbre fabriquant de pneus avait utilisé le slogan "Sans maîtrise, la puissance n'est rien". Ce slogan va comme un gant à C++, C++ est très puissant et ultra performant, à condition que le programmeur qui l'utilise sache l'exploiter, et savoir l'exploiter c'est aussi savoir que C++ n'est peut être pas le langage idéal pour faire ce que l'on veut faire.
C++, est un langage de programmation difficile, peut être même le plus difficile de tous les langages de programmation. Croire qu'on va pouvoir tout faire avec C++ en en suivant un tuto est un leurre. La maîtrise de C++ demande des années d'efforts, et donc une motivation qui va bien au delà d'un désir infantile passager. Ce sera dur, ce sera long, si ta motivation flanche au bout d'une semaine, parce que le cours est trop austère, c'est que de toute façon tu n'avais aucune chance au départ...
Comme beaucoup de programmeurs de mon age, j'ai appris les bases tout seul, sans aucune aide (internet à l'époque, c'était de la science-fiction, obtenir un bouquin qui n'était pas publié en France était compliqué). Si je m'étais à l'époque découragé devant "l’austérité" du cours de gbdivers (j'aurais bien aimé en avoir un à l'époque), il est plus que probable que je n'aurais jamais posté le moindre message sur ce forum.
Salut gbdivers, est-ce que tu ouvrirais une partie Comparateur « Compare », pour les algorithmes de recherches ? Comme : std::map, std::set, std::unordered_set …
Je sais qu’à chaque fois, je retourne sur le cours d’OC pour vérifier mon implantion « Point2DCompare », et franchement ça m’exaspère … D’autant plus qu’il y a plein d’autre types implantations (Point3DCompare, Segment2DCompare, Segment3DCompare, StringCompare … ) !
Et surtout, le plus important, c’est comment en créer, et quelle logique aborder ! Savoir si c’est mieux de surcharger les opérateurs « < » et « == » ou bien de créer un comparateur qui utilise la méthode « operator(...) ». De comprendre pourquoi utiliser des règles de conditions, tel que par exemple « (lhs.x != rhs.x) » dans le comparateur d’un points 2D, avant de tester les sous conditions, ce qui donne : « return (lhs.x != rhs.x) ? (lhs.x < rhs.x) : (lhs.y < rhs.y); »
Enfin, pas de soucis, c’est au cas ou, tu souhaiterai partager des idées de conception à ce niveaux-là. En tout cas, merci pour ton cours !!!
- Edité par Hip (Zeos) 20 mai 2017 à 13:01:26
« Les détails font la perfection, et la perfection n'est pas un détail » Léonard de Vinci
La vraie question, celle qu'il faudrait que tu te poses, est pourquoi as tu besoin de retourner vérifier ton implémentation (sur OC ou ailleurs)?
Crois tu que que je valide mes implémentations (de quoique ce soit) en allant vérifier sur un site quelconque? La réponse est non, le code est valide parce que je l'ai conçu pour qu'il soit valide. La seule chose qui dira si mon code est valide ou pas, ce sont les tests et rien d'autre.
Ce sera dur, ce sera long, si ta motivation flanche au bout d'une semaine, parce que le cours est trop austère, c'est que de toute façon tu n'avais aucune chance au départ...
Non je ne suis pas d'accord, ce sera dur peut-être, long sans aucun doute, mais cela ne veut pas pour autant dire que tu n'as aucune chance si t'es pas motivé par le cours, en l'occurrence ici de qualité dans son contenu. Combien d'élèves aujourd'hui n'aiment pas les mathématiques par ex ? Plein, et d'expérience je peux te dire que c'est tout simplement dû d'une part à la difficulté de la matière mais intrinsèquement aux lacunes pédagogiques des professeurs (ça c'est une chose) et aussi (et là pour le coup c'est valable dans plein de matières) dû à la motivation donnée aux élèves, entre autre la dynamique du cours. Il se trouve que pas de bol, les maths en terme de dynamisme c'est peut-être plus compliqué qu'une autre matière au vue de l'abstraction de la matière, et puis de base c'est compliqué, car naturellement pas aussi intuitive pour certains élèves, et après les lacunes pédagogiques mais osef ici ça nous concerne pas (j'entends lacunes pédagogiques par pertinence et qualité du cours). Après pour être honnête des cours motivants et dynamiques c'est très rare à l'Education Nationale, cependant le contenu que l'on peut trouver sur Internet est généralement plus populaire car plus dynamique / interactif etc même s'il n'est pas parfait désolé de vous décevoir mais OC en fait partie
C++ c'est pareil, c'est compliqué, du moins pr qqn qui n'a jamais programmé une seule fois, alors si le cours est dynamique/motivant très honnêtement je pense que ça aide énormément. Donc désolé, un cours parfait c'est un cours qui répond aux attentes de n'importe quel lecteur (OC le fait plutôt bien), et qui suit une ligne qui permet d'atteindre un niveau de qualité (ce que fait pas OC, d'autant plus qu'il ne s'attarde presque pas au C++, mais plus à sa syntaxe, ce qui est peu c'est vrai, mais occupe, d'expérience, les débuts d'un débutant pendant un moment)
A part ces deux lignes je suis entièrement d'accord avec vous str4nger et int21h
le contenu que l'on peut trouver sur Internet est généralement plus populaire car plus dynamique / interactif etc même s'il n'est pas parfait désolé de vous décevoir mais OC en fait partie
(Pour le cours OCR).
Plus populaire, oui.
Plus dynamique, non. Il semble plus dynamique parce qu'il survole beaucoup de notions, ce qui donne une impression d'aller vite. Ce qui en fait plus un tutoriel ou une introduction qu'un cours.
Et plus interactif, non plus. Il n'y a aucun élément d’interactivité en plus par rapport a un cours donne dans une école IRL. (Voire moins, puisque sur un cours en ligne, beaucoup ne font pas les exos, ils se contentent de lire le cours).
Impressive-Now a écrit:
qui répond aux attentes de n'importe quel lecteur (OC le fait plutôt bien)
Je ne suis pas d'accord : le cours OCR ne répond pas du tout aux attentes de quelqu'un qui souhaiterait apprendre sérieusement le C++. (Puisque qu'il faudra oublier ce que l'on a appris dans ce cours si on approfondi le C++).
Et si quelqu'un ne souhaite pas apprendre sérieusement le C++, alors (a mon sens), c'est une erreur d'apprendre le C++. C'est préférable de se diriger vers un autre langage.
Tu trouves que le cours OCR est bien fait parce qu'il répond aux attentes de certains lecteurs. Je trouve qu'il est mal fait parce qu'il n'explique pas a ces lecteurs que c'est probablement une erreur d'apprendre le C++.
Bien sûr qu'il survole, mais c'est volontaire, je pense que tu ne te rends pas à compte à quelle point qqn qui n'a jamais programmé aime bien un cours qui se suffit à la syntaxe du langage, c'est déjà beaucoup pour lui (ça l'était pour moi, déjà que j'avais du mal avec les pointeurs, puis ensuite les classes je comprenais même pas la logique de la syntaxe, je faisais tu copier coller pour être sûr de ne pas faire d'erreur de syntaxe, pourtant elle me semble pas du tout compliqué aujourd'hui au contraire : après c'était peut-être mal expliqué, mais ce qui est sûr c'est qu'il était suffisamment simpliste pour que je reste motivé (pour moi motivé = ok la programmation c'est pas non plus infaisable, je vais y aller pas à pas tkl, je me dis pas "ok développeur c'est mort")).
Je me mets juste à la place d'un public, que je pense est conséquent
Et plus interactif, non plus
Oui tu as raison, je me suis pas assez bien exprimé précisément, j'incluais le manque d’interactivité avec le même s'il n'est pas parfait
Je ne suis pas d'accord : le cours OCR ne répond pas du tout aux attentes de quelqu'un qui souhaiterait apprendre sérieusement le C++. (Puisque qu'il faudra oublier ce que l'on a appris dans ce cours si on approfondi le C++).
Et si quelqu'un ne souhaite pas apprendre sérieusement le C++, alors (a mon sens), c'est une erreur d'apprendre le C++. C'est préférable de se diriger vers un autre langage.
Tu trouves que le cours OCR est bien fait parce qu'il répond aux attentes de certains lecteurs. Je trouve qu'il est mal fait parce qu'il n'explique pas a ces lecteurs que c'est probablement une erreur d'apprendre le C++.
Pour quelqu'un qui travaille déjà dans l'informatique ou même juste qu'il connaît bien un autre langage (et donc connaît au moins vite fait les rouages de la programmation) ton cours est parfait pour lui, je dois reconnaître que d'aller sur le cours d'OCR serait totalement inutile pour lui.
Tkt pas je suis venu ici juste pour te signaler que ton cours est orienté pour certaines personnes dont je n'ai pas fais partie, je me suis donc permis de te le dire, ou peut-être te le rappeler si tu en avais déjà conscience, pour qu'ainsi les questions auxquels tu te posais (déduction de types avant autre chapitre etc) puisse trouver peut-être une réponse en reprenant cela en considération Après c'est vrai que si personnellement un jour je devais faire un cours C++ je serais plutôt attaché à l'apprendre à un public qui n'a jamais programmé, et faire en sorte si c'est possible de plaire aussi à ceux qui ont déjà programmé. Je ne me suis pas assez penché sur la question pour savoir si on peut réconcilier les deux, mais c'est que j'essaierai de faire a priori.
Ton argument qui contre ce que je dis est que ceux qui n'ont jamais programmé et qui commence par le C++, font une erreur.
Peut-être que tu as raison, je n'est pas assez d'expérience pour prouver le contraire, si ce n'est encore une fois mon expérience : J'ai fais une erreur ? Est-ce que ça m'a ralenti dans mon apprentissage de l'informatique ? Suis-je une exception ? Bien évidemment je pense que non, peut-être que j'ai tort.
Et pour ce qui est des mauvaises habitudes, je pense pas que cela n'existe pas vraiment en programmation, on ne fait que progresser, si on doit enlever using namespace dans telle ou telle circonstance on le fait (en plus d'avoir en bon élève cherché à comprendre pourquoi), il n'y a pas de "réflexe" / habitudes, comme ça peut être le cas, d'expérience, dans l'apprentissage d'un instrument de musique par ex, ou aussi d'un jeu vidéo
Ta comparaison avec les maths ne tient pas. Les maths, on ne te demande pas ton avis, tu dois les apprendre car ça fait partie de l'enseignement obligatoire. Les gamins de 15 ans qui font des maths pour le plaisir sont plutôt rares.
Le c++ n'est pas du tout obligatoire (du moins pas à 15 ans), donc tu es tout seul. Tu pourras avoir le meilleur cours de l'univers, il n'y a que ta volonté pour te pousser, si elle n'est pas au rendez-vous, c'est perdu d'avance.
Et je rejoins gbdivers sur le fait que c++ n'est peut être pas le langage idéal pour débuter. Les jeunes se lancent souvent dans c++ parce qu'ils croient, à tort, qu'au bout de quelques semaines, il seront capable de réaliser les jeux AAA de leurs rêves, puis la réalité les rattrape, et ils découvrent qu'ils se sont lancé là dedans pour de mauvaises raisons.
c++ n'est probablement pas le langage idéal pour débuter, mais c'est aller un peut vite en besogne que de dire qu'on ne peut pas débuter avec c++
- Edité par int21h il y a 15 minutes
techniquement, on peut débuter avec quasiment n'importe quel langage. (*)
Le souci, c'est de savoir ce qu'on vise en débutant, et le temps que ça mettra pour arriver à le faire correctement.
(*) il se trouve même que le langage n'est pas le facteur le plus important dans l'apprentissage. Cf. une expérience - un peu à contre-courant - en cours à Stanford pour commencer par javaScript au lieu de Java. https://computinged.wordpress.com/2017/04/21/cs-department-updates-introductory-courses-java-is-gone/
Apprendre le C++ à des gens qui n'ont jamais programmé, c'est clairement une mauvaise idée de toute façon. Ce n'est pas un langage pour débuter.
Syntaxiquement le C++ peut être très intuitif pour un débutant (comme d'autres langages) donc à partir de là je ne vois pas en quoi ce n'est pas un langage pour débuter. Certes le débutant produira du code idiot au vu de ce que peut faire le langage mais ce n'est pas du tout un problème : il ne prendre pas (je pense et d'expérience) de "mauvaises habitudes" ça n'existe pas en programmation (à part si on s'est lancé dans un gros projet et qu'on veut adopter un autre modèle de conception, mais là on parle plus de code débutant)
c++ n'est probablement pas le langage idéal pour débuter
Idem, même sur la première partie de ta phrase je suis en désaccord. ou du moins il faudrait être plus précis.
Pour faire du code simple de débutants le C++ n'a rien de plus difficile qu'un autre ! Les concepts qui l'entourent, sa rigueur etc sont peut être plus compliqués à manipuler et exploiter qu'un autre je veux bien l'admettre, mais là on est vraiment hors cadre du débutant. Autrement dit je pense qu'avec le C++ on peut aller du très simple au très "compliqué" si on le souhaite, dans un autre langage on ira peut-être du très simple au un petit peu compliqué, pcq la finalité du langage n'est pas forcément difficile à prendre en main, contrairement au C++ j'imagine. De plus, je ne pense pas que d'apprendre et commencer par le C++ nuise à l'apprentissage de la programmation de manière générale, on peut y trouver une certaine continuité et une pente douce dans l'apprentissage sans faire face à un moment à une grande marche qui nous bloque ou une pente un peu trop raide qui nous ralenti là où un autre langage ne nous ralentirait pas.. (j'espère que je vous ai pas perdu dans cette image x) )
Après encore une fois c'est le débutant qui parle ici, il y a même pas un an mon code était écris en français, il y avait des using namespace en .h, il y avait 4 fonctions à identifiants près, identiques, j'avais des classes qui stockais plus des données qu'autres choses (avec des accesseurs en veux tu en voilà), ou qui avait trop de responsabilités à la fois, j'utilisais des pointeurs nues, j'utilisais limite que std::vector (ou plutôt "vector" ) pour stocker des objets, je continuais même à utiliser des tableaux brutes quand je connaissais la taille (plutôt qu'array), j'évitais d'utiliser les itérateurs pcq j'avais pas trop compris à quoi ça servait, les algorithmes de la std encore moins, la généricité limite je savais pas que ça existait, les foncteurs non plus... etc 'fin bref la liste est longue, et pourtant me voilà ici aujourd'hui, je connais une très grande partie de la std, je mets de la généricité un peu partout, j'exploite les algorithmes de la std. Aujourd'hui j'ai conscience que je ne suis qu'à une partie du chemin, puisque je ne me suis pas encore habitué à manipuler par exemple les classes de traits et politiques (j'en comprends déjà mieux pourquoi et où les utiliser), ou aussi au passage, je ne mets pas encore d'assertions static.
Et j'ai totalement conscience que sans classes de traits/politiques, oui on peut faire des choses mais on se prive je pense d'une bonne partie de la formalisation que l'on peut faire avec le C++
Tout ce bloc pour vous dire à quel point j'étais nul, et à quel point je le suis encore (avec quelques nuances j'espère), et que cela ne m'a pas empêché d'atteindre le niveau que j'ai aujourd'hui, ni même (et ça je ne peux pas en être sûre mais vu à quel point j'étais perdu dans l'informatique de manière générale) que je pouvais aller plus vite dans mon apprentissage avec un cours comme celui de gbdivers (franchement, je pense que j'aurais été perdu, votre argument étant qu'un débutant qui ne connaît rien à la programmation grosso modo n'a rien à faire sur le cours de gbdivers, car n'a rien à faire sur un cours C++, car le C++ n'est pas fait pour ce genre de débutants)
Le C++ n'est pas un langage que l'on apprend en 1 an, ni même que c'est un langage que l'on manipule parfaitement en 2-3 ans, là où d'autres langages s'apprennent en quelques mois et se manipule très bien en 1 an. Ni même que C++ est un langage pour les jeux vidéos. Il se trouve que (et c'est pour ça que j'aime beaucoup le langage C++, peut-être à tort encore une fois, vous me le direz) le langage C++ peut simuler beaucoup de concepts (j'pense à l'ECS évidemment), personnellement j'ai l'impression que si demain on me demande de conceptualiser un projet, le C++ peut répondre à tous mes besoins. Certes d'autres langages ont déjà intégré dans sa définition tel ou tel concept, et c'est là qu'il faut faire la part des choses et choisir le bon langage.
En bref, je rejoins michel :
techniquement, on peut débuter avec quasiment n'importe quel langage. Le souci, c'est de savoir ce qu'on vise en débutant, et le temps que ça mettra pour arriver à le faire correctement.
J'ai commencé le C++ parce que j'avais entendu dire qu'il était "bien pour les jeux vidéos". Très bien, on peut nuancer cette assertion, mais tout de même.
Peut-être qu'effectivement je pensais pouvoir faire un jeu plutôt rapidement. Bon pour un tetris c'est largement possible, la question c'est plutôt, pour faire un jeu vidéo complexe, vraiment complet, qui peut être facilement modifié, et peut évolué rapidement, là... c'est vrai qu'il faut (beaucoup) plus de notions (je vous l'avoue j'étais presque étonné qu'il y ait des concepts de programmation, limite je pensais qu'un programme se résumait à de la production de code, aujourd'hui bien évidemment je suis totalement opposé à ces propos).
Bon du coup ça devient un peu hors sujet, quoique ma conviction c'est de dire qu'un défi serait de faire un cours universel, qui peut prendre en considération le public dont j'ai fais partie, à condition d'admettre (et ça personne peut trancher, on ne discute que sur nos expériences) que l'apprentissage du C++ à des débutants est pertinent, et environ aussi"rapide" que l'apprentissage d'un autre langage.
Et pour terminer, le but de mon intervention était encore une fois de souligner que le cours de gbdivers est orienté vers un public (que beaucoup d'entre vous considère comme le seul légitime à suivre un cours de C++), et que les questions qu'il peut se poser quant à son agencement peut trouver une réponse en considérant le public dont il a affaire =)
Pour faire du code simple de débutants le C++ n'a rien de plus difficile qu'un autre ! Les concepts qui l'entourent, sa rigueur etc sont peut être plus compliqués à manipuler et exploiter qu'un autre je veux bien l'admettre, mais là on est vraiment hors cadre du débutant.
Là tu te contredis. Si c'est plus compliquer à manier, c'est plus difficile pour un débutant.
La question est de savoir si, pour un débutant qui commence (!), on se permet de relâcher les règles et de laisser tomber, pour simplifier, les considérations qui peuvent avoir une grande importance pour de la programmation professionnelle.
Par exemple supposer que les additions d'entiers ne débordent jamais, que les allocations réussissent toujours, etc. faute de quoi le programme tout bête "lire deux entiers et afficher la somme" est déjà une galère (tester si les deux lectures échouent => ça demande de gérer deux si-alors-sinon)
La question est de savoir si, pour un débutant qui commence (!), on se permet de relâcher les règles et de laisser tomber, pour simplifier, les considérations qui peuvent avoir une grande importance pour de la programmation professionnelle.
Je parlais plutôt des concepts (POO entre autres), pas vraiment les erreurs matérielles qui sont valables pour tous les langages (du moins en ce qui concerne les débordement par ex). Donc oui selon moi on peut relâcher les règles, on peut les définir plus tard ce n'est à mon sens pas incohérent. On définit ce qu'est un entier naturel avant d'apprendre à compter ? non et pourtant la définition d'un entier naturel c'est plutôt la base pour un mathématicien, pour moi c'est la même chose ici
Si tu prefères, je trouve ça dommage d'apprendre des concepts, certes simples pour nous, mais compliqués (et ça je pense que vous avez dû mal à le comprendre) pour un débutant, comme 'auto it = v.begin()' préféré à 'std::vector<int>::iterator it = v.begin()'. C'est bête, mais je pense qu'il faut pas s'y prendre de cette manière. Car plus il va utiliser std::vector<int>::iterator, plus il va non seulement comprendre à quel point auto est magique, mais aussi comprendre quand l'utiliser, car il aura compris vraiment la logique du compilateur.
Quelqu'un qui connaît déjà la programmation, autant lui expliquer 'auto', mais un débutant, il a déjà du mal à comprendre l'opérateur :: (c'est con mais je vous assure que c'est vrai, en tout cas pour moi) il sait pas d'où ça sort le '::' c'est déjà beaucoup pour lui. D'ailleurs je me rappelle que je comprenais pas vraiment le vector<int>, genre pour moi c'était un type bizard, alors qu'en faites c'était un type à qui on donne des types en paramètres tout simplement (alors par ex sur ce sujet c'était probablement pas suffisamment explicité dans le cours d'ocr)
Quand vous voyez mes explications vous vous dites "oulaaaa celui là il doit pas être bon en programmation!!" mais ne vous inquiétez pas j'ai un peu progressé depuis (ça pour le coup ça date d'il y a quelques années)
Ton explication sur auto tape plutôt à côté. Si on suit ta logique, il ne faut pas apprendre la programmation avec Python, ou avec OCaml, ou avec Haskell, ou avec ... on peut en faire une liste longue comme le bras, parce qu'on indique les types explicitement nulle part.
auto, ça ne veut pas dire qu'on ne sait pas de quel type est une expression, ça veut dire qu'on sait que le type de la variable déduit par le compilateur est le bon pour ce qu'on en fait. (*)
A un débutant, il est préférable d'apprendre, avant les itérateurs, la manière moderne de parcourir un conteneur de bout en bout, ce qui suffit pour beaucoup de situations.
Déjà, faire la différence entre
for (auto var : conteneur) {
...
}
// et
for (auto & var : conteneur) {
...
}
c'est pas mal. Les itérateurs, on peut en parler quand on introduit quelques fonctions d' <algorithm>. Ah, aussi quand on fait un find() sur une map. Sinon, tant qu'on peut s'en passer autant le faire.
(*) inversement, désormais mettre explicitement un type (un peu compliqué), c'est prévenir le programmeur suivant que le type "auto" ne faisait pas forcément l'affaire, et donc l'inciter à y regarder de plus près. Un moyen de lui faire perdre du temps !
pour un débutant, comme 'auto it = v.begin()' préféré à 'std::vector<int>::iterator it = v.begin()'. C'est bête, mais je pense qu'il faut pas s'y prendre de cette manière. Car plus il va utiliser std::vector<int>::iterator, plus il va non seulement comprendre à quel point auto est magique, mais aussi comprendre quand l'utiliser, car il aura compris vraiment la logique du compilateur.
C'est quoi "std::vector<int>::iterator" ? C'est une classe ? Un type fondamental ? Un alias de type (typedef) ? Autre chose ?
Peut etre que tu donneras une réponse au hasard et que ca sera juste, mais il est fort probable que ta vrai reponse sera "je ne sais pas".
Tu crois que auto est "magique" parce que tu as appris "std::vector<int>::iterator" en premier. Mais tu n'as pas realise a quel point "std::vector<int>::iterator" etait "magique" pour toi. (Tu utilises le même argument que ceux qui disent qu'il faut apprendre le C en premier langage, parce que cela permet de savoir ce qui se passe à l'intérieur. Sans réaliser qu'ils ne savent en fait rien du tout de ce qui se passe à l'intérieur).
--------
Ca va te paraitre étrange, mais j'ai l'impression que tu as le syndrome de l'expert (oui oui, même si tu n'es pas un expert). Tu connais des choses et tu as du mal a te projeter dans quelqu'un qui ne sait pas. Paradoxalement, même si tu es plus débutant que plusieurs intervenants ici, je pense que tu as beaucoup plus de mal à comprendre les débutants.
Savoir se détacher de comment on a appris, de sa propre expérience, pour mettre en place une pédagogie destinée à d'autres personnes, c'est très compliqué. Cela demande de maîtriser son domaine (*) et de prendre du recul.
(*) Cela ne veut pas dire qu'un débutant ne peut pas écrire un tuto ou un cours. Mathieu l'a très bien montré. Et ca m'est arrivé d'écrire des tutos sur des domaines que je découvrais. Mais on ne peut dans ce cas que restituer une pédagogie que l'on a reçu, pas mettre en place une vraie pédagogie.
@ImpressiveNow: Syntaxiquement c++ est intuitif pour toi, parce que tu le connais, mais si tu prends un débutant absolu, la syntaxe de c++ n'est pas d tout intuitive (cf les remarques de Michel Billaud sur les opérateurs par exemple). Si tu prends un langage comme Pascal, sa syntaxe est vraiment très intuitive, c'est presque du pseudo code. De ce point de vue là pascal est à des années lumières de c++. Ce qui n'est pas très étonnant, pascal a plus ou moins été conçu spécifiquement pour l'apprentissage de la programmation.
Et comme l'on dit mes petits camarades auto n'est pas magique, plutôt que de donner le type, je demande au compilateur de le déduire. Le principe est assez simple, si je donne le type, j'ai une chance non négligeable de me tromper, alors que le compilateur ne se trompera pas. Je suis très expérimenté, le risque que je me trompe de type est extrêmement faible (mais il existe et c'est pour ça que j'utilise auto). Par contre un débutant, quel est le risque qu'il se trompe de type? maximal.
Ne vous inquiétez j'ai compris le principe d'auto x) (d'ailleurs je suis agréablement surpris de voir votre enthousiasme à m'expliquer les choses c'est très respectable vraiment !!) je disais magique car dans la syntaxe d'une déclaration de variable en c++ ça évite d'écrire le type, comme en C (mais en C les types ne s'imbriquent pas de toutes façons je crois, il y a que des variables (dont pointeurs de fonctions)), en plus d'éviter au compilateur de faire une deuxième vérification inutile comme l'a souligné michel et dont bien entendu j'étais au courant. Il se fait tard je m'expliquerai davantage demain
Si ce n'est, pour que gbdivers puisse rebondir, que std::vector::iterator est un type, savoir si c'est un alias type fondamental ou classe ça ne m'intéresse pas, tt ce que je dois savoir c'est qu'il (l'objet) est léger en mémoire (input) et donc le passage par valeur si possible peut être adopté, et qu'il permet de parcourir un tableau à temps constant (random access) dans les deux direcrions (bidirectionnal) et je me rappelle plus les deux dernières propriétés mais la dernière qui le spécifie encore plus est le faite qu'il puisse modifier la valeur qu'il pointe, contrairement à l'itérateur de set qui ne peut pas la modifier car la modification ne pourrai pas garantir la validité du set si valeur existe déjà, et de toutes façons rendrait l'arbre qui le définit invalide puisque le noeud est rangé selon sa clé
Et qu'il vérifie plein d'autres propriétés sans aucun doute spécifiées dans la doc (les plus simples copie, comparaison == etc)
std::vector::iterator est un type, savoir si c'est un alias type fondamental ou classe ça ne m'intéresse pas
On est bien d'accord, cela n'a pas d'intérêt.
Et utiliser "std::vector<int>::iterator" n'apporte aucune information supplémentaire par rapport a "auto". On a juste besoin de savoir que begin/end retournent des itérateurs et connaître les propriétés des itérateurs. (De mémoire, dans mon cours, il y a juste une note pour dire "le type réel retourne par begin/end est un peu complexe et s'écrit ..., mais osef pour le moment de la cuisine interne, c'est purement informatif")
Ton argument est bon. Personnellement j'introduirais les types de manière générale avant 'auto', histoire qu'on sache que std::vector<int>::iterator n'a rien de bizard, juste un type déclaré dans une structure (pas banal pour un débutant). C'est juste ça qui me dérange. Pcq après il y a le risque qu'il utilise auto un peu partout et l'enlève quand le compilateur ne l'accepte pas. Il va certes comprendre quand l'utiliser à un moment, mais autant faciliter les choses : "un type ça peut être ça, ça, ou ça, mais parfois on peut s'éviter de les écrire quand on déclare une variable [pas uniquement que pour ça mais chaque chose en son temps, on peut parler des avantages machines plus tard], voilà pourquoi et comment", et au moins là on est sûre que le lecteur a compris à quoi peut ressembler un type (int ok, std::vector<int>, std::pair<int, std::vector<float>>, ou aussi std::vector<int>::iterator), et comprendra mieux l'utilité d'auto
C'est aussi ma réponse à gbdivers, du coup je considère pas que ce n'est pas important :S c'est un choix moi je trouve que c'est important de connaître toutes les syntaxes d'un type, où ça peut se trouver, avant d'utiliser auto. En gros je suis d'accord qu'on s'en fou comment ça s'écrit, tout ce qu'on veut c'est l'utiliser et connaître ses propriétés, par contre je préférerais expliquer les types de manière générale avant d'utiliser auto. Je vois auto comme un privilège, et je préfère expliquer la syntaxe brute propre au C++ (<type> <affectation>) j'abrège il y en a plein d'autres, et ensuite, une fois qu'on a compris à quoi ressemble un type, on explique auto, sa logique/force (tout de suite intuitive pour le lecteur).
Syntaxiquement c++ est intuitif pour toi, parce que tu le connais, mais si tu prends un débutant absolu, la syntaxe de c++ n'est pas d tout intuitive
Ha désolé je me suis peut-être mal exprimé, je suis tout à fait d'accord avec toi, le fond de ma pensée étant que le C++ n'a rien de moins intuitif (je parle de la syntaxe "du début", déclarations, boucles etc) selon moi que ses voisins que vous considériez peut-être à apprendre avant le C++ (vous me direz si je me trompe) je pense au Java
Et comme l'on dit mes petits camarades auto n'est pas magique
Je sais bien pourquoi et quand utiliser auto, j'entends magique par le fait qu'il évite des choses, en l'occurence des types, inutiles puisqu'il évite au compilo de vérifier si le type retour du calcul est égal au type de la variable (dans le cas d'une initialisation de variable) et ne gêne pas pour autant la compréhension du code (au contraire). Enfin bref on s'est compris je pense
Bon la prochaine fois je ferais des réponses plus courtes, j'aime beaucoup la pédagogie mais tout de même :S j'étais pas venu pollué le post à la base, juste (encore une fois x) ) dire que les réponses aux questions de gbdivers peuvent peut-être trouver une réponse si on se rappelle la ligne directrice du cours =) tout ce qui est important c'est que le cours garde une forme de logique, même si elle n'est pas la mienne
Ton argument est bon. Personnellement j'introduirais les types de manière générale avant 'auto', histoire qu'on sache que std::vector<int>::iterator n'a rien de bizard, juste un type déclaré dans une structure (pas banal pour un débutant). C'est juste ça qui me dérange. Pcq après il y a le risque qu'il utilise auto un peu partout et l'enlève quand le compilateur ne l'accepte pas. Il va certes comprendre quand l'utiliser à un moment, mais autant faciliter les choses : "un type ça peut être ça, ça, ou ça, mais parfois on peut s'éviter de les écrire quand on déclare une variable [pas uniquement que pour ça mais chaque chose en son temps, on peut parler des avantages machines plus tard], voilà pourquoi et comment", et au moins là on est sûre que le lecteur a compris à quoi peut ressembler un type (int ok, std::vector<int>, std::pair<int, std::vector<float>>, ou aussi std::vector<int>::iterator), et comprendra mieux l'utilité d'auto
Et là dessus j'ai un contre exemple tiré de ma propre expérience :
J'ai fait une bonne partie des exo sur CodinGame (que je recommande d'ailleurs), mais je me rappelle il y a quelques mois avoir pas mal galéré sur un exercice qui faisait un gros usage de std::map. L'objectif était de mettre un type MIME en clé et obtenir la chaine correspondante en valeur, sauf que pour une très grosse entrée (~10k) ma map était tout simplement trop lente et je pétais le temps d'exécution max pour cet exercice. Il s'avère que j'utilisais une boucle foreach de ce genre
Sauf que ! Dans une map, la clé n'est pas un type "simple", le const lui est automatiquement attribué : mon code passait donc beaucoup trop de temps à faire des copies complètement inutiles (des tests plus tard m'ont montré que je passais entre 15 et 20% de mon temps à copier des trucs) alors que je voulais des références à la base.
Du coup, on fait comment, on apprend aux débutants absolument tous les types de retour/copie/référence de toutes les fonctions qui existent, ou bien on utilise un outil très intéressant quand bien utilisé ?
C'est simple : j'utilise pas auto si je sais pas à quoi j'ai affaire
Après tout pourquoi pas utiliser auto, dans des cas comme auto var = 3.14f, mais pas à toutes les sauces, comme l'exemple de l'itérateur : je ferais le choix d'apprendre "voilà à quoi ressemble le type itérateur de mon vecteur : vector<int>::iterator (sans se soucier de savoir si c'est un alias etc, juste voilà comment je peux l'écrire, ce qui peut être une nouvelle notation pour le lecteur), et ainsi il utilisera auto s'il le connaît déjà, pcq il en connaît les rouages, sinon il l'apprendra après et comprendra aussi très facilement son fonctionnement car le lecteur fait face aux problèmes qu'auto résout.
Ce qui me dérange c'est de faire passer auto avant la syntaxe, ok on n'a pas à savoir quel est le type exact (nom), mais juste la syntaxe, ou disons sa position dans les structures de données, surtout si elle est nouvelle. Certains considérerons que ça n'a pas de sens de raisonner comme ça, mais moi si, je considère auto comme un privilège, pas comme une bonne habitude que doit prendre un débutant sans même réfléchir à quoi peut ressembler/ où se positionne le type dans la conceptualisation du code
Votre argument c'est de dire, quand on a auto it = v.begin() tout ce qu'on doit savoir c'est qu'on a un objet qui peut parcourir le tableau avec telle et telle propriété : bah pour moi vous allez flouter complètement l'aperçu que peut avoir le lecteur sur le concept, il va être perdu "waaaa ok auto it et hop j'ai un truc qui me permets de faire des trucs de malades comment ils ont fait ça" l'intention est bonne, mais à mon avis c'est le ressenti d'un débutant
On voit clairement une grosse différence d'implémentation, Visual définit ses itérateurs dans une classe de base, alors que gcc les définit comme des classes indépendantes. Les deux choix sont valides tant que les propriétés attendues de l'itérateur sont au rendez-vous. Du coup quelle est la valeur de l'information apportée par std::vector<T>::iterator ? à peu près nulle, la seule chose importante, c'est qu'on est en présence d'un objet qui possède les propriétés d'un random access iterator telles que définies par la norme. On voit bien que selon le compilateur que tu utilises, le type nommé std::vector<T>::iterator est différent, par contre il a les mêmes propriétés, or ce qui nous intéresse, ce sont ses propriétés, du coup son nom, on s'en fout, il ne nous apporte aucune information utile.
Votre argument c'est de dire, quand on a auto it = v.begin() tout ce qu'on doit savoir c'est qu'on a un objet qui peut parcourir le tableau avec telle et telle propriété : bah pour moi vous allez flouter complètement l'aperçu que peut avoir le lecteur sur le concept, il va être perdu "waaaa ok auto it et hop j'ai un truc qui me permets de faire des trucs de malades comment ils ont fait ça" l'intention est bonne, mais à mon avis c'est le ressenti d'un débutant
- Edité par Impressive-Now il y a environ 9 heures
Nope. Ce que je dis à mes débutants, c'est
1) qu'il y a une notion d'itérateur, qui sert à parcourir une séquence. Qu'on peut le positionner sur le début (begin), avancer (++), et tester si on est sorti de la séquence. et qu'on accède ç l'élément visé par */
2) le fait que end() ne désigne pas le dernier est déjà une source de questionnements. Et que begin() n'est pas forcement le premier non plus (séquence vide).
3) pour assimiler ça il faut faire quelques exercices. Se convaincre que ça marche. S'habituer aux tournures, parce qu'on n'est plus au siècle dernier où les C++ débutants connaissaient un peu C, et étaient accoutumés au parcours de tableau (chaine) par pointeur et au parcours de listes (p = p->suivant) qui sont du même style
4) après on peut revenir à la définition précise du type des iterateurs. Quand on leur dit "quand vous parcourez un vecteur de string, le type de l'itérateur est std::vector<std::string>::iterator", ça ne les surprend pas, mais ils comprennent pourquoi on met auto. Ca prend le type kivabien, et si on a des raisons de mettre autre chose, on verra.
Les trucs de ouf, c'est pas auto qui les fait. C'est la notion d'iterateur. Indépendemment de la manière de déclarer une variable itérateur.
de toutes façons, le std::vector<std::string>::iterator ils vont forcément tomber dessus dès qu'ils vont aller à la pêche aux solutions sur Google, vu les quantités de code "pre-c++11" qui ne sont pas prêt de disparaitre d'internet.
Très bon cours, je le suit en parallèle avec celui de OC (Que je trouve plus "pédagogique" mais moins beaucoup complet) et je me demander si il y avais quelques part les corrections des exercices, car étant débutant, j'aime bien regarder les corrections même si mon exo fonctionne pour voir où et comment j'aurai pu améliorer mon code pour qu'il soit plus clair / plus fonctionnel.
Le meilleur moyen de prédire l'avenir, c'est de l'inventer | N'oubliez pas [résolu] et +1 | Excusez mon ôrtograffe, j'essaie de l'améliorer...
Discord NaN. Mon site.
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.
Discord NaN. Mon site.