(et le C++11, c'est has-been, on fait du C++1y maintenant )
- Edité par gbdivers il y a environ 1 heure
J'ai lu le plan vite fait, ça ne serait pas plus logique de mettre "Environnement de développement" vers le début du cours ? Quelqu'un n'y connaissant rien en programmation et voulant débuter en aura forcément besoin pour faire les tp au dessus
Nop, c'est volontaire, les exos (au début) se font directement en ligne (via ideone ou coliru pour le moment)
Si par "installation d'un environnement de développement", on entend "installer Code::Block ou Qt Creator ou MSVC", l'intérêt est limité. L'apprenant ne comprend pas ce qu'il fait et n'a aucune idée du processus de compilation. Au final, il ne sait pas réellement installer un environnement de développement
Si par "installation d'un environnement de développement", on entend... "installer un environnement de développement", alors c'est quelque chose de beaucoup plus complexe, et en même temps beaucoup plus puissant, que d'installer C::B/Qt/MSVC. Et cela ne se fait pas en 1 leçon et cela ne se fait pas dès le début du cours. Il faut y aller progressivement. Dans le premier cours "Programme C++ minimal", il y a juste la compilation d'un main.cpp en ligne de commande. Ensuite il y aura la complation multi fichier et le linkage, l'installation des outils annexes (ide, vérification statique, gestionnaire de versions, etc)
Mais cela sera vu progressivement (et pas simplement un IDE, mais l'environnement complet)
Ca, c'est une machination faite par les entreprises qui vendent des débogueurs, pour extorquer de l'argent aux pôvres développeurs que nous sommes. Un code C++ correctement écrit est un code bug-safe !
Le cours n'explique pas comment faire des bugs, alors personne n'en fait.
J'ai bien rigolé en lisant ça ! Je crois que je vais le noter dans ma listes des perles de réponses de forums !
Non sérieusement, je sais que c'était dans l'optique du tuto de ne pas présenter de pointeurs nus, mais même sans ça il peut y avoir des plantage (genre division par 0) qu'on peut avoir du mal à trouver sans expériences et sans debbuger !
Une division par 0 n'est pas une erreur, ça produit un Inf ...
En fait ça dépend ! parce que sinon :
x = y
x-y = 0
2(x-y) = 0
2(x-y) = (x-y) car (x-y) = 0
2 = (x-y)/(x-y) car division par 0 autorisée = 1 => Conclusion 2 = 1 !
Sinon, qu'est ce qui est expliqué dans le cours ? Que ça provoque un comportement indéterminé (oui j'aime reprendre les termes de la norme ) ? Même si on le sait sur de gros programmes on peut faire l'erreur après ...
Une division par 0 n'est pas une erreur, ça produit un Inf... et c'est expliqué dans le cours
C'est bien spécifié tel quel dans le standard C++, ou tu te base sur l'IEEE754 ? Autant le fait que inf soit normalisé dans le standard, OK, mais le fait que le standard stipule que la division par zéro donne inf m'étonne.
Et oui, voilà le genre de choses auxquelles on fait attention quand on est habitué au C ! Nyark !
EDIT : non, rien. J'ai bien fait de relire ton cours plus attentivement : la réponse est dedans.
Tu ne peux pas passer de "2(x-y) = (x-y)" à "2 = (x-y)/(x-y)". Une équivalence est conservée uniquement "si tu divises les deux membres de l'égalité par un même nombre non nul". Ce n'est pas le cas, donc il n'y a pas équivalence et ta démonstration est fausse
Et non, ce n'est ni une erreur, ni un comportement indéterminé. Inf est parfaitement définie dans la norme IEEE 754
Et 1000 p c'est rien. La formation que je donne au taf a dans les 400-500 slides -- et on présuppose des bases en développement (c'est le moins que je demande pour un public en ssii)
Je crois que c'est là qu'il y a un problème, si on essaie d'utiliser C++ comme langage pour débutants qui n'ont aucune base préalable en programmation. Il y a trop de choses qui interfèrent dès le départ (Passage de paramètre par copie => constructeur par copie => ...)
Ce n'est pas ça mon problème. Mon problème c'est qu'il y a déjà bien assez de choses à voir côté C++ & bonnes pratiques pour ne pas avoir aussi à enseigner les rudiments de l'algorithmie. Et quand on n'a que 5 jours, et pas 6 mois, ben ... on fait des coupes en exigeant des prérequis. SSII => public de base normalement initié au développement => pratique passée en Java/C/Python/... et exposition scolaire préalable aux pointeurs attendue, et à la différence entre paramètre formel et réel.
>SSII => public de base normalement initié au développement
Ouaif, là c'est pas gagné, pour les grouillots oui, mais pour ceux sont catapultés chef de projet voir plus dés la sortie d'école parce qu'il (mais plus elle) n'aiment pas le dev., le pré-requis c'est plus Excel.
P.S.: mince, on n'est plus trolldi.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Ces catalputés là tu ne les (lire: "ils ne se") mets pas au dev C++. S'ils ont envie de technique, ils feront du python, voire du ksh pour les anciens.
J'ai fini de lire les cours disponible et je doit dire que c'est très complais, bravo .
J'aime beaucoup l'apprentissage "par anecdote" (je n'ai pas d'autre mot). Comme par exemple : "On utilisera cette ligne de pré-processeur : #include". L'élève n'avais jamais entendu ce terme avant mais la prochaine fois qu'il tombera sur un cour traitant les commandes de pré-processeur, il ne sera pas perdu par le vocabulaire.
- Edité par robinson des bois 17 juin 2014 à 10:21:06
Mon point de vue : dans un cours, pour des raisons pédagogiques, on ne peut pas tout voir. Par contre, c'est une erreur pédagogique (à mon sens) que l'étudiant ne sache pas qu'il existe d'autres notions que celle qu'il a dans le cours. Donc, ne pas étudier toutes les commandes de pré-processeurs n'est pas grave, par contre il doit savoir ce qu'est une commande pré-processeur (accessoirement savoir ce qu'est un pré-processeur ) et savoir qu'il y en a d'autres non vues dans le cours
C'est pour cette raison que je donne aussi les termes anglais
@A ceux qui corrigent les fautes
Merci... c'est dingue la quantité d'erreur que je fais
Je ferais un passage dans un correcteur de toute façon quand le cours sera plus avancé (sur Antidote probablement)
Merci... c'est dingue la quantité d'erreur que je fais
Je ferais un passage dans un correcteur de toute façon quand le cours sera plus avancé (sur Antidote probablement)
Je sais que tu as l'intention de relire ton cours lorsque celui-ci sera plus avancé, mais je ne suis pas sûr qu'un correcteur automatique soit indispensable. Même si (et je ne sais même pas de quoi je parle) ce correcteur est performant, à mon avis, il faudra surtout faire revoir par des débutants l'ensemble du cours, je m'explique:
Personnellement, je me considère comme débutant en C++ (cours du SdZ entièrement lu/assimilé, et certaines notions abordées encore à pratiquer + des éléments C++11 appris par curiosité et en lisant ton cours), et j'avoue que certaines parties m'ont l'air de manquer de détails, c'est à dire que moi, comme je suis un débutant++ (comprenez débutant qui a déjà acquis les micros-bases), j'ai ressenti un certain manque sur certaines parties que je retrouverai sûrement en re-lisant.
Du coup, la vision idéale de la chose serai la suivante:
Créer un système de "commentaires en direct", c'est à dire un petit "fourre-tout" comme il y avait sur le SdZ au lancement de la nouvelle version (si tu ne vois pas de quoi je parle, j'expliciterai plus), et inciter très fortement les débutants à dire TOUT ce qui leur passe par la tête quand ils lisent (genre "Ha tiens là je me souviens plus de ça" ou "Oulha! Allons revoir ces notions au chapitre d'avant ^^"). Après, je comprends bien que ce que je propose ici n'est qu'une version idéalisée de la chose... Dans l'hypothèse où un tel système de commentaire serait mis en place, je ne suis pas sûr que les débutants pensent systématiquement à poster un commentaire.
Pour te donner un exemple, je viens de lire 2-3 chapitres du cours (les 2-3 derniers dans le fil du cours tel que le site le propose, en suivant le "chapitre suivant"), et je me suis dis dans ma petite tête de nooby du C++11: "Tiens! C'est quoi une littérale déjà? Je l'ai lu ça dans le cours? Je m'en souviens plus :O".
Bon... Je pense avoir fait le tour de ce que j'ai vu ce soir, si une autre remarque me vient à l'esprit, je te la ferai parvenir Ha si! Une dernière remarque! Merci pour le passage sur la déclaration des variables avec {}! Je ne savais pas que dans ce cas, une vérification était faite (et pourtant, j'avais cherché, sans succès :/).
Il s'agit de deux choses différentes : la relecture pour la "mise en forme" (présentation, CSS, orthographe, grammaire, tournure des phrases) et la relecture pour le fond (la pédagogie, bien expliquer les choses, dans le bon ordre, etc)
Quand je parle de faire passer le correcteur automatique, cela concerne que le premier point (même le plus idiot des relecteurs automatiques fera moins de faute que moi )
Pour le second point, il y aura forcement beaucoup de changement lorsque je m'occuperai d'ajouter la partie pratique (exos, tp, projets). Si tu ne te souvenez plus du terme "littérale", c'est pas parce que je ne l'utilise pas assez (j'arrête pas), mais parce que n'as pas écris toi même du code en revenant 10 fois sur le terme "littéral"
Quand j'ai appris le C++, j'ai dû lire 10 fois qu'il fallait mettre un point-virgule après une définition de classe. J'oubliais systématiquement de le mettre. Au bout de 100 fois à refaire l'erreur, je ne l'ai plus oublié
Pour {}, j'ai l'impression que l'on voit peu dans les tutoriels le pourquoi des choses et surtout qu'est ce qui se passe quand on fait une erreur. En montrant clairement les messages d'erreurs, on démystifie le compilateur (c'est notre copain) et on "prouve" concrètement qu'il existe une syntaxe meilleure qu'une autre (le C++11 n'a pas été créé que pour les "experts". C'est avant tout un outil puissant pour les débutants)
Pour les commentaires dans le cours, c'est une idée à creuser. Mais pour le moment, le site est un simple wiki de base en php, il faudra probablement écrire ce module de commentaire et donc trouver une personne pour s'en occuper (ça ne sera pas ma priorité)
+1 pour l'utilisation du terme "littéral", au moins maintenant je ne risque pas de l'oublier
Lorsque tu parles des erreurs faîtes, et des Warning/Error du compilateur, je suis d'accord avec toi... Pour le peux que j'ai pu lire, j'ai du apprendre par moi même à décoder les erreurs du compilateur, parfois plus que barbares (et souvent avec l'aide de mon moteur de recherche ^^) et sans aide extérieure :(. C'est vrai qu'avec le temps, on se rends compte de plus en plus que le compilateur est génial! Mais le problème c'est que c'est "avec le temps" En tous cas ton approche au niveau des {} m'a totalement convaincu de l'utilité de l'utilisation de liste d'initialiseurs (c'est bien ça le nom?), comparativement aux parenthèses normales (ou au int x = 0;).
Et pour finir, ce que j'ai exposé avec le "commentaire furtif" n'est qu'une idée comme une autre, à prendre, à laisser, ou à garder pour plus tard! Je pense moi même que cette idée n'est pas du tout la plus utile, mais qui sait? Elle va rester dans un coin de ta tête, et peut-être un jour quand tu auras un peu de temps, ressortir (ou alors sombrer dans les méandres de tes neurones, et être oubliée à jamais ).
l'utilisation de liste d'initialiseurs (c'est bien ça le nom?)
Nop. On parle parfois de "braket-initialization" ou "uniform initialization" (initialisation avec des crochets et initialisation uniforme - pour des raisons historiques, car uniformisation avec les "aggregate-initialization" des tableaux style C), mais le terme "officiel", c'est "initializer-list" (appel d'un constructeur spécifique) ou "aggregate-initialization" (dans le cas d'initialisation sans constructeur)
En particulier, il ne faut pas confondre "initializer-list" (syntaxe du type {1,2,3}, n'a pas de traduction française "officielle") avec la liste d'initialisation (dans un constructeur, c'est à dire A() : a(), b() {}, appelé "member initializer list" en anglais).
IdeOne garantie que les codes ne sont jamais effacé, ce qui est bien pour donner des exos. Mais : pas de Clang, pas de GCC 4.9. Pas accès aux lignes de commandes. Pas de warnings quand le programme réussit à compiler
Coliru : ne conserve pas les codes sur le long terme. Par contre, Clang 3.4. Pas de Clang 3.5 et GCC 4.9. Accès aux lignes de commandes et aux warnings
Coliru : ne conserve pas les codes sur le long terme. Par contre, Clang 3.4. Pas de Clang 3.5 et GCC 4.9. Accès aux lignes de commandes et aux warnings
En réalité, GCC 4.9 est présent dans coliru. Par contre il faudra utiliser ceci pour l'invoquer:
/usr/local/bin/g++-4.9
Il y a aussi le problème avec ideone qui n'accepte pas le multithread.
Ah je viens de remarqué que c'est la version par défaut. Par contre, pour clang. Il n'ont pas encore la dernière version. (D'ailleurs, étant donné que ça utilise GCC comme backend ça perd un peu de son intérêt; il reste aussi les jolis messages d'erreur et autres spécificité, mais moi j'utilise clang surtout pour ne plus avoir affaire à libstdc++).
Je viens de découvrir http://cpp.sh/ (utilisé sur cplusplus.com), qui utilise GCC 4.9. Le point intéressant est que Boost 1.49 est également disponible dans cet IDE (je n'ai pas testé les autres IDE en ligne pour voir quelles libs externes sont dispo)
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.