Je dirais hypocritement qu'un new sur une petite classe de 16 octets n'échoue jamais sur un PC (en effet, si t'as plus une seule page de RAM dispo, ça veut dire que ça swap à mort depuis des lustres, le PC est à la rue, et l'utilisateur ou un quelconque programme de monitoring aura rebooté le machin bien avant que tu aies une exception sur un tout petit new). Donc le fait que le programme crashe sur une exception est... disons, anecdotique, vu que le PC est déjà mort.
Pas forcément, on peut vouloir limiter les ressources accessibles à un processus avec ulimit ou par d'autres moyens, dans ce cas-ci un new peut échouer alors que la machine a encore suffisament de ressources pour fonctionner correctement.
On ne le fait nécessairement exprès pour faire échouer new, on peut vouloir limiter l'utilisation de certaines ressources comme la mémoire pour des raisons pratiques (sécurité/serveurs, test, …).
- Edité par Mad scientist 31 décembre 2016 à 16:30:42
Je dirais hypocritement qu'un new sur une petite classe de 16 octets n'échoue jamais sur un PC (en effet, si t'as plus une seule page de RAM dispo, ça veut dire que ça swap à mort depuis des lustres, le PC est à la rue, et l'utilisateur ou un quelconque programme de monitoring aura rebooté le machin bien avant que tu aies une exception sur un tout petit new). Donc le fait que le programme crashe sur une exception est... disons, anecdotique, vu que le PC est déjà mort.
Tu oublies un point : "new A" peut échouer avec d'autres exceptions que std::bad_alloc.
Donc pas de débat : un cours DOIT aborder la question de comment gérer une allocation qui échoue. Et c'est le point de départ du RAII et des pointeurs intelligents.
Mais si ta remarque vise à pointer le fait qu'il n'est pas nécessaire d'encadrer chaque new par un try-catch, je suis d'accord. D'ailleurs, dans le cours C++ actuel, qui aborde en seconde partie Qt (qui n'utilise pas les exceptions), cela serait problématique de dire dans la première partie qu'il faut blinder les utilisation de new, puis de ne pas le faire dans la seconde partie.
A mon sens, le point important dans les questions de koala01, c'est que ce n'est pas focalisé sur des questions de syntaxes (ce que font beaucoup de cours et d'exos de C++), mais l'acquisition de concepts fondamentaux. (Par contre, assimiler un concept prend forcément du temps et passe obligatoirement par l'apprentissage de la syntaxe dans un premier temps. C'est pourquoi "au plus tard deux chapitre après avoir rencontré pour la première fois le mot clé new" est peut être exagéré).
Oui enfin bon, les pointeurs intelligents et le RAII (plus généralement) ont une justification beaucoup plus large que l'échec d'une allocation.
C'est la levée d'une exception, quelle qu'elle soit, sur le chemin entre le moment où on a alloué une ressource et le bout de code qui devait faire sa libération. Et la levée de l'exception peut ne rien avoir à faire avec une allocation dynamique. Comme cause, faut pas faire une fixette sur l'allocation dynamique.
Une autre raison pour les pointeurs intelligents, c'est les situations notoirement emmerdantes à gérer, comme la co-propriété. Exemple, on alloue des objets qui, initialement, sont ajoutés à 2 listes, dans des parties différentes du code qui ne sont pas censées se connaitre. De temps en temps on enlève des élements de l'une ou l'autre. On veut qu'ils soient libérés quand ils n'intéressent plus personne.
- Edité par michelbillaud 1 janvier 2017 à 11:43:21
Ben, à vrai dire, à mon sens, les notions de sémantique de valeur / sémantique d'entité et d'exceptions (principalement ce qui arrive quand elles sont lancées) devraient même apprises (pour ne pas dire comprises, ce qui est encore différent) AVANT d'aborder le concept d'allocation dynamique de la mémoire et l'utilisation de new.
je ne prétend absolument pas que ce soit un objectif facile à atteindre, et encore moins qu'il y a moyen de l'atteindre. Mais, cey objectif est à mon sens le seul moyen de permettre au récipiendaire de prendre pleinement conscience de tous les enjeux qu'un simple mot clé (new) peut contenir
- Edité par koala01 1 janvier 2017 à 18:19:19
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
C'est fou, tous ces concepts qui doivent absolument être vus les uns avant les autres :-)
oui, bien sur... surtout en C++... Mais pas seulement :
Tu ne saurais sans doute pas expliquer la notion de boucle avant d'avoir expliqué celle de condition; et tu ne saurais sans doute pas expliqué cette dernière avant d'avoir au minimum expliqué la notion de variable (pour les langages impératifs), de valeur et /ou celle de "valeur d'entrée" et de "valeur de sortie" (pour les langages fonctionnels).
Mais, j'ai lu dans un livre "la programmation est comme un tour de magie pour les gens : ils vous voient taper sur le clavier et, abracadabra, vous obtenez le résultat que vous espériez" (c'est une citation de tête, d'un bouquin écrit en anglais, avec toute l'interprétation que cela suppose )
Or, le fait est que, à partir du moment où tu dis bien aux gens : "cela vous semblera peut-être magique dans un premier temps, mais, plus vous en saurez, plus vous arriverez à comprendre les tours que je vous montre", cela te permet de... partir sur des voies inexplorées jusqu'à lors
Ce qu'il y a de bien avec C++, c'est que tu n'es absolument pas limité à un paradigme particulier : tu n'est pas forcément obligé de taper une fonction (que tu devras rendre statique) dans une classe; même si il faudra sans doute expliquer aux gens que vector.push_back est une fonction qui s'applique spécifiquement à la variable "vector"
Et, du coup, tu peux très bien aborder la notion de structure (sans fonctions membres !!! ) sur des notions "simples", comme la notion de date, d'heure ou ... de point.
Puis tu peux continuer en expliquant la notion d'encapsulation et celle d'interface, en citant Meyers qui dit "une interface doit être facile à utiliser correctement et difficile à utiliser de manière erronée" ou encore la loi de Finagle qui dit que "si on laisse la possibilité à quelqu'un de faire une connerie, il finira tôt ou tard par la faire".
Il n'est même pas encore besoin d'aborder les concepts de "substituabilité" ou de "comportements polymorphes" à ce stade; il suffit juste d'apprendre aux gens à penser "en termes de comportements / de services rendus" alors que nous même nous avions à la base appris à penser "en termes de données", et de bien leur faire comprendre qu'un comportement est beaucoup plus stable que la représentation des données utilisées pour mettre ce comportement en oeuvre : add(truc1, truc2) représente un comportement bien établi, équivalent à calculer la somme ou toute notion plus ou moins identique quelle que soit la manière dont truc1 et truc2 sont représentés
Les notions de date, d'heure et de points (et les structures que tu auras créées pour les représenter) seront très utiles pour démontrer le fait que l'on s'attend systématiquement à disposer de quatre services de base pour ces abstractions :
la possibilité de les créer
la possibilité de les copier
la possibilité d'affecter la valeur de l'une à une autre variable
la possibilité de s'assurer que "le ménage est fait" lorsque l'on n'en a pas besoin
Et cela te permet d'introduire la forme canonique orthodoxe de Coplien si tu le souhaite, tout en précisant que C++ fournit ces quatre services (à l'aide de "fonctions spéciales" respectivement nommées "constructeur par défaut", "constructeur de copie", "opérateur d'affectation" et "destructeur") pour toute structure ou toute classe pour laquelle nous ne lui donnons pas de raison de faire autrement.
Au plus tard tout juste après avoir introduit cette forme canonique, il faudra penser à introduire la notion de référence (si cela n'a pas été fait avant), et à bien expliquer que le passage d'une référence à une fonction ne provoque pas la copie de l'argument, par opposition au passage par valeur.
Puis tu peux utiliser des notions plus complexes, comme celles de "personnage" (dans un jeu, par exemple), de "véhicule" ou de "compte bancaire", et faire comprendre les risques qu'il peut y avoir à permettre aux (classes / structures) éléments qui permettent la représentation de ces notions dans le code d'être copiées (et / ou affectées).
Et c'est justement l'occasion parfaite d'introduire ces notions de "sémantique de valeur" Vs "sémantique d'entité". ¨Puis tu raffines un peu ton exemple : le personnage peut être un troll, un guerrier, ou un elfe; le compte bancaire peut être un compte courant ou un compte d'épargne; le véhicule peut être un sous-marin, un avion ou un vélo.
Tu peux donc introduire la notion de "comportement polymorphes" et de "substituabilité", car tout véhicule peut "accélérer" ou "ralentir", tout personnage peut "attaquer", tout compte bancaire peut "percevoir un montant" ou "débiter un montant", mais le type réel (dynamique) du personnage, du véhicule, du compte bancaire influera sur la manière dont ces comportements sont mis en oeuvre.
Il sera temps à ce moment là d'introduire le LSP, et de bien faire comprendre qu'il s'agit de la règle absolue à respecter pour que la substituabilité puisse fonctionner; pour que tu puisse transmettre n'importe quel troll, elfe ou guerrier à une fonction s'attendant à recevoir un personnage comme paramètre; pour que tu puisse transmettre n'importe quel vélo, avion ou sous-marin à une fonction s'attendant à recevoir un véhicule comme paramètre, que tu puisses transmettre n'importe quel compte courant ou compte d'épargne à une fonction s'attendant à recevoir un compte bancaire en paramètre.
Et si tu dois parler des pointeurs, de l'allocation dynamique de la mémoire et des pointeurs intelligents, hé bien cela se fera sans doute au cours d'une des étapes représentées par les trois derniers paragraphes de cette intervention, de préférence en commençant par les pointeurs intelligents et les fonctions make_unique / make_shared (restons moderne ), en parlant des pointeurs nus, de new et de delete ensuite
Bien sur, tôt ou tard, tu te retrouveras confronté aux restrictions conceptuelles de la notion de tableau. Il faudra donc sans doute aborder les concepts de piles, de files, de liste et d'arbres binaires et, comme on est en C++, introduire les classes de la STL qui correspondent à ces concepts
Enfin, tu pourras terminer -- s'il te reste un peu de temps -- en abordant l'aspect générique du langage (les template), et ce sera peut être l'occasion de ... "dévoiler tes secrets de magiciens" concernant les classes de la STL que tu auras abordées, en faisant comprendre que, oui, elles font sans doute appel à new et à delete à un moment ou à un autre, mais que l'on n'avait pas besoin de le savoir vu qu'on savait comment les utiliser correctement
EDIT: je me rend compte que j'ai oublié de parler de la notion d'exception. Hé bien, la meilleure occasion pour en parler te sera sans doute donnée lorsqu'il s'agira d'aborder le LSP, car il te permettra (c'est là dessus qu'il se base après tout) d'introduire la programmation par contrat, et donc de distinguer les "erreurs de logique" -- qui doivent être résolue directement dans le code AVANT que le projet ne soit proposé aux gens -- des erreurs contre lesquelles le développeur n'a aucun autre moyen de se prémunir que de partir du principe "qu'elles peuvent arriver" parce que le "système étendu" (l'ordinateur, ses périphériques éventuels, mais aussi les serveurs auxquels l'application se connecte peut être) dans lequel l'application est utilisée pose un problème.
Et, à partir du moment où cette distinction est claire, tu peux introduire la notion d'exception, à utiliser pour "gérer ces situations exceptionnelles", et donc, introduire la manière dont elles font réagir l'application quand elles surviennent en C++
EDIT (bis) : je viens de me rendre compte que, bien qu'un peu sommaire, je viens de définir le plan d'un cours que je jugerais volontiers comme "idéal"... Avis aux amateurs )
- Edité par koala01 2 janvier 2017 à 14:33:58
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Je crois que le sens du message de michelbillaud était de rappeler que ça fait beaucoup de concepts à casser dans un cours avec une contrainte de temps. Ce qui fait que soient les concepts sont survolés et mal assimilés, soient certaines concepts passent a la trappe.
Ce que tu confirmes un peu avec la longueur de ton message
EDIT :
michelbillaud a écrit:
gbdivers a écrit:
C'est pas un probleme debutant non-initiés, mais un problème d'investissement que l'apprenant est prêt à mettre dans l'apprentissage du C++.
Par exemple il pourrait investir dans l'apprentissage des bases de la programmation, puis, se lancer dans C++.
Séparer un cours de 40h qui aborde les bases de la programmation et le C++ en un cours de 20h sur les bases de la programmation et un cours de 20h sur le C++ ne changera rien au problème si le but de celui qui lit le cours souhaite simple avoir un cours de 10h sur les bases de la programmation, le C++, la 3D, la création de jeux vidéos, pour créer le plus rapidement possible son super JV de la mort mieux que WoW.
Le cours C++ du SdZ est accessible à cette catégorie de personnes, pas le mien. C'était le sens de ma remarque.
@koala01 : Il y a longtemps, quand j'ai appris fortran (IV) dans une autre galaxie, la seule boucle qui existait dans le langage était la boucle DO (sur un intervalle), et je crois que c'était pareil en Basic. Les autres étaient réalisée par des tests et goto.
Je dis pas qu'il faut regretter le bon vieux temps https://www.youtube.com/watch?v=DTch2Z6pn0w mais ça convenait assez bien pour le type de choses qu'on pour commencer, à savoir du calcul bourrin sur des suites, des séries, des matrices... et ça donnait une notion de boucle. On peut aussi faire beaucoup de choses (au début) avec des parcours de conteneurs par "foreach", ou parcours d'intervalle (en Python), le temps de faire acquérir quelques notions de base (cumul dans une boucle, maximum, ...)
@gbdivers << Je crois que le sens du message de michelbillaud était de rappeler que ça fait beaucoup de concepts à caser dans un cours avec une contrainte de temps. >>
Y a ça, et le fait qu'il y a, en C++, une dépendance circulaire entre concepts. Exceptions => utiliser les classes d'exceptions => hiérarchie => objets => etc.
Je pense que le truc, c'est que vous avez affaire à des programmeurs qui connaissent au moins un peu ces notions, et à qui vous vous efforcez d'expliquer comment les utiliser systématiquement, correctement, et dans les règles de l'art. C'est très bien, mais expliquer ça à ceux à qui - pour l'instant - ces notions ne disent absolument rien, c'est une toute autre histoire : il s'agit de passer la première couche, voire même la couche d'apprêt.
Au passage, le truc du "pour l'instant c'est magique mais on verra plus tard", pédagogiquement, c'est à utiliser avec des pincettes. Le programmeur débutant, il a déjà tendance à accuser les forces obscures quand son programme ne marche pas, faut pas le pousser en dehors de la rationalité, il doit toujours avoir en tête un modèle conceptuel clair de ce que ça fait (même si ça n'explique pas comment ça le fait) et de pourquoi il le fait.
Evidemment, il y a un compromis à trouver quand les explications ne font qu'ajouter des couches d'incompréhensions (ah bon, c'est quoi un espace de noms ? Pourquoi on en a besoin ? C'est quoi les includes ? D'où ils sortent ?)
@gbdivers : je suis bien conscient que le facteur temps est primordial : c'est (à part le pouvoir d'achat des profs) le facteur essentiellement visé quand il s'agit de réduire les ressources dans l'espoir de "faire plus avec moins", mais, malheureusement, c'est aussi le seul facteur qui puisse permettre à quelqu'un d'espérer atteindre une certaine maîtrise à force de pratique, tous domaines et tous langages confondus.
Et pour notre malheur, notre "langage de prédilection" compte sans doute parmi les langages les plus complexes que l'on puisse trouver. Si bien que, pour arriver à une excellente maitrise de tous les aspects du langage, il faut commencer à compter la pratique (de préférence sur des problèmes variés, avec des solutions variées) s'étalant sur plusieurs années.
Je ne crois pas que diviser un cours de 40 heures en deux cours de 20 heures changerait énormément de choses, mais je suis malgré tout convaincu (oui, c'est mon expérience personnelle qui parle) que le fait d'apprendre correctement (ce qui signifie : sur une durée raisonnable pour en permettre l'assimilation, à savoir à peu près 40 heures) les principes de base de la programmation avant d'aborder le moindre langage (lui aussi sur une durée d'à peu près 40 heures) faciliterait énormément l'apprentissage des différents langages; quitte (pour tout ce qui est de l'apprentissage des langages orientés objets) à s'assurer que les principes de la programmation orientée objets soient, eux aussi, assimilés avant même que l'étudiant ne doive commencer à les utiliser en "situation réelle" (dans leur code, au travers du langage de programmation visé par l'apprentissage).
michelbillaud a écrit:
@koala01 : Il y a longtemps, quand j'ai appris fortran (IV) dans une autre galaxie, la seule boucle qui existait dans le langage était la boucle DO (sur un intervalle), et je crois que c'était pareil en Basic. Les autres étaient réalisée par des tests et goto.
Je dis pas qu'il faut regretter le bon vieux temps https://www.youtube.com/watch?v=DTch2Z6pn0w mais ça convenait assez bien pour le type de choses qu'on pour commencer, à savoir du calcul bourrin sur des suites, des séries, des matrices... et ça donnait une notion de boucle. On peut aussi faire beaucoup de choses (au début) avec des parcours de conteneurs par "foreach", ou parcours d'intervalle (en Python), le temps de faire acquérir quelques notions de base (cumul dans une boucle, maximum, ...)
Malheureusement, comme tu le dis si bien, c'était "il y a bien longtemps, dans une autre galaxie"...
Je lis actuellement un livre (principes des langages de programmation) qui reprend justement l'histoire -- depuis la réflexion de Von Neumann se disant que le programme et les données pourraient se trouver en mémoire jusqu'à nos jours -- qui explique bien le phénomène dés le premier chapitre : Avant Von Neumann, il fallait carrément "tirer des fils" pour créer les différentes connexions représentant les calculs que l'on voulait faire.
Après Von Neumann, tous les langages de programmation ont du faire des choix afin de concilier trois aspects parfois antagonistes :
L'efficacité à l'exécution
la facilité avec laquelle on écrit le code et
la facilité avec laquelle le code peut être compris par quelqu'un
Mais le gros compromis à faire tient dans le cursus de celui qui lira le code : un mathématicien (ou assimilé) préférera voir un code prenant d'avantage la forme d'une "formule" (mathématique) qu'un code prenant la forme d'une suite d'instruction, alors que ce sera l'inverse pour un "non mathématicien".
Et tous les langages de programmations utilisent depuis le même raisonnement en choisissant un "niveau d'abstraction" suffisant pour se démarquer "suffisamment" des instructions réellement comprises par le processeur afin de se rapprocher "autant que possible" d'une représentation qui soit "suffisamment compréhensible par un humain"... Et le tout (mais c'est peut être demander le beurre et l'argent du beurre, sur ce coup), si possible, en garantissant les meilleurs performances à l'exécution
Le truc, c'est que les ordinateurs étaient essentiellement utilisés dans des domaines très particuliers à l'époque de Fortran ou d'algol, alors que maintenant, quasiment tout le monde a un (voir plusieurs, si on compte les tablettes et les smartphones) ordinateur à sa disposition immédiate; et qu'on leur en demande (aux ordinateurs, s'entend) de plus en plus.
Et c'est là qu'est tout le problème : beaucoup d'applications ou de projets à long termes deviennent de plus en plus complexes et nécessitent des niveaux d'abstraction de plus en plus élevés, "simplement" pour leur assurer une certaine pérennité ( en améliorant leur capacité à se voir adjoindre de nouvelles fonctionnalités, ou en facilitant la chasse et la correction des erreurs qui ne manqueront pas d'apparaitre)
Y a ça, et le fait qu'il y a, en C++, une dépendance circulaire entre concepts. Exceptions => utiliser les classes d'exceptions => hiérarchie => objets => etc.
Hummm... ca, ca "reste à voir" comme dirait l'autre...
Oui, la bibliothèque présente une hiérarchie de classes correspondant à certaines "exceptions types";
Oui, cette hiérarchie est régulièrement utile lorsque l'on souhaite, à certains endroits, ne s'inquiéter que d'un certain type d'exception bien précis et, à d'autres, pouvoir s'intéresser à un nombre d'expressions bien plus vastes
Mais non, tu n'as absolument aucune obligation d'intégrer tes propres expressions dans cette hiérarchie de classe, pas plus que tu n'as l'obligation d'utiliser une classe pour représenter une expression
Je vais sans doute me faire trucider pour l'avoir abordé, mais -- bien que ce ne soit vraiment, mais alors là vraiment pas conseillé -- un code proche de
void foo(){
/* du code */
if(condition)
throw 2;
/* encore du code */
}
void bar(){
/* du code "safe"
try{
/* du code */
foo()
/* encore du code*/
}catch(int i){
/* qu'est ce qu'on fait ? */
}
/* encore du code "safe" */
}
sera tout à fait valide
Je pense que le truc, c'est que vous avez affaire à des programmeurs qui connaissent au moins un peu ces notions, et à qui vous vous efforcez d'expliquer comment les utiliser systématiquement, correctement, et dans les règles de l'art. C'est très bien, mais expliquer ça à ceux à qui - pour l'instant - ces notions ne disent absolument rien, c'est une toute autre histoire : il s'agit de passer la première couche, voire même la couche d'apprêt.
On est bel et bien conscient du problème. Et, d'une certaine manière, c'est toute la différence entre un cours écrit et "en acces libre" et un cours "oral" (ou du moins présenté par une personne "de référence" à laquelle le récipiendaire peut demander des explications
Mais il faut aussi se dire que les premiers sont souvent utilisé comme support pour les deuxièmes.
Ceci dit, je comprends parfaitement le dilemme du "référent" qui hésite à trop se démarquer de l'ouvrage sur lequel il base son cours (peut-être parce qu'il "n'a pas trouvé mieux"!!!), au risque de perdre toute crédibilité face à son auditoire (j'imagine très bien deux élèves discutant : l'un "hé, t'as vu, le prof nous dit blanc ici, mais le bouqin nous dit noir", l'autre "ah oui, tu as raison... Mais quel con ce prof!").
Et c'est bel et bien la raison pour laquelle je plaide pour une séparation nette entre l'apprentissage de "la théorie" (principes "de base" et / ou "avancés" de la programmation en générale) et l'apprentissage de la mise en pratique au travers d'un langage particulier. Et c'est aussi la raison pour laquelle je plaide (mais je suis d'avantage suivi sur ce point) pour une séparation stricte de l'apprentissage des différents langages : on apprend C OU C++ OU ... n'importe quel autre langage "sympa", mais on n'apprend pas C ET C++, en même temps, dans un cours "de C/C++"; pas plus que l'on apprendrait C++ et... java ou C et... pascal durant le même cours
Au passage, le truc du "pour l'instant c'est magique mais on verra plus tard", pédagogiquement, c'est à utiliser avec des pincettes. Le programmeur débutant, il a déjà tendance à accuser les forces obscures quand son programme ne marche pas, faut pas le pousser en dehors de la rationalité, il doit toujours avoir en tête un modèle conceptuel clair de ce que ça fait (même si ça n'explique pas comment ça le fait) et de pourquoi il le fait.
Oui, bien sur !!! On pourrait peut être tempéré les choses en disant plutot "cela a peut être l'air magique, mais ca l'est pas du tout... faudra juste attendre un peu pour que vous vous en rendiez compte"
Et le pire, c'est que tu es en plus toujours "pris par le temps", et que "plus tard", ca peut facilement se transformer en "jamais" si tu "traines trop" en chemin
Evidemment, il y a un compromis à trouver quand les explications ne font qu'ajouter des couches d'incompréhensions (ah bon, c'est quoi un espace de noms ? Pourquoi on en a besoin ? C'est quoi les includes ? D'où ils sortent ?)
Tout à fait... Mais tu as les mêmes problèmes avec n'importe quel langage "moderne" : remplace les espaces de noms par les module, les include par import, et tu auras les mêmes questions de la part d'étudiants apprenant (comme premier langage de programmation) java, ruby ou python
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Ceci dit, je comprends parfaitement le dilemme du "référent" qui hésite à trop se démarquer de l'ouvrage sur lequel il base son cours (peut-être parce qu'il "n'a pas trouvé mieux"!!!), au risque de perdre toute crédibilité face à son auditoire (j'imagine très bien deux élèves discutant : l'un "hé, t'as vu, le prof nous dit blanc ici, mais le bouqin nous dit noir", l'autre "ah oui, tu as raison... Mais quel con ce prof!").
Faudrait déjà qu'ils écoutent le prof, et qu'ils lisent des bouquins :-/
Les "apprenants" (du moins les miens, qui sortent du lycee) ont une vision fausse du rôle des cours. Ils s'imaginent que, comme dans les écoles du moyen age, le cours est l'endroit conçu pour que les élèves aient l'occasion d'avoir une source d'information (le cours récité par le prof qui lit ses notes) qu'ils peuvent recopier à la plume d'oie, et étudier ensuite, le soir à la chandelle.
Comme depuis on a inventé les bouquins, les photocopieuses et Internet, à quoi ça sert qu'ils copient quoi que ce soit ? Et à quoi ça sert d'écouter, puisqu'il n'y a pas besoin de copier ? Et à quoi ça sert de réfléchir aux problèmes et exercices, puisqu'on trouvera une solution à copier coller depuis le premier truc en français trouvé sur Google, et/ou dans les cours du site du zero ?
Un des soucis d'Internet, c'est que les cours d'informatique périmés restent !
Sur "la théorie" : même en IUT, les étudiants râlent que "c'est théorique". Et en même temps qu'on leur donne trop de projets :-)
- Edité par michelbillaud 3 janvier 2017 à 9:16:11
Personnellement, comme je l'ai déjà dit, j'ai eu des cours séparés, et je ne me suis jamais plaint du fait que les cours de "principes de programmation" étaient trop théoriques...
Mais il faut dire que j'avais un prof génial sur ce point, qui n'hésitait pas à nous lancer des défis, ni à se faire "aussi bête qu'un ordinateur" lorsqu'il s'agissait de "valider" un algorithme proposé par un étudiant. Et, comme en plus, c'étaient des cours du soir, je présume que la motivation et la "nature" même des étudiants était aussi tout autre
Je comprends donc aussi qu'il ne pourrait pas agir de la même manière devant une classe d'élèves qui espèrent (même s'il ne l'avoueront jamais) seulement que "leur diplôme leur tombe tout cuit entre les mains" au risque de "perdre toute crédibilité"; même si j'ai aussi fait l'expérience (en secondaires) de profs qui ne comprenaient pas la moitié du cours qu'ils lisaient et d'autres qui n'hésitaient pas à faire vivre leur cours, et pour lesquels nous avions malgré tout un grand respect
C'est pour cela que, si on prend la peine de ne pas chercher "le responsable unique" de la situation actuelle , on peut malgré tout regretter une grande disparité dans l'état d'esprit des profs, et que tous ne soient pas hyper motivés à l'idée d'approfondir et d'améliorer leur connaissances des sujets qu'ils traitent.
Mais bon, ce n'est bien sur qu'une remarque générale, qui n'attaque aucun prof en particulier : comme je l'ai dit, j'ai connu des profs qui étaient hyper motivés et dont les cours étaient de véritables régals... Mais c'était aussi "au siecle passé" (en d'autres temps :P). Et puis, de toutes manière, "tout le monde" est coupable ici : les élèves pour leur manque d'implication dans leurs études, le ministère pour ne pas donner les moyens nécessaires à l'enseignement et les profs pour ne pas forcément être "aussi motivés" qu'ils pourraient l'être dans de meilleurs circonstances. Je me garderai donc bien de ne jeter la pierre qu'aux enseignants
michelbillaud a écrit:
Un des soucis d'Internet, c'est que les cours d'informatique périmés restent !
Oui, il est clair que cela n'aide absolument pas... surtout quand les dits cours sont intimement reliés à un forum qui revendique le fait de s'adresser aux débutants
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Les étudiants qui sortent du lycée ont à la fois une motivation pour ce qu'ils font (au moins pour certains) et aussi un comportement forgé par des années de collège-lycée où ils subissaient des cours qu'ils n'avaient pas choisis.
On peut à la fois se sentir très intéressé et ne pas avoir envie de bosser, surtout quand ce qu'on entend ne correspond pas directement à ce qu'on pense (évidemment sans aucun recul) être utile.
"L'allocation dynamique, ça tombera au devoir ?"
- Edité par michelbillaud 3 janvier 2017 à 13:46:35
Les étudiants qui sortent du lycée ont à la fois une motivation pour ce qu'ils font (au moins pour certains) et aussi un comportement forgé par des années de collège-lycée où ils subissaient des cours qu'ils n'avaient pas choisis.
Aussi... Ce qui tend à prouver que nous ne pouvons pas nous contenter de les blâmer et eux seuls
On peut à la fois se sentir très intéressé et ne pas avoir envie de bosser, surtout quand ce qu'on entend ne correspond pas directement à ce qu'on pense (évidemment sans aucun recul) être utile.
C'est justement ce manque de recul qui est la base de tout le problème...
Le PO original a pris "la mouche" parce le recul donne de nombreuses raisons à ceux qui le font de critiquer le cours d'OC, alors que le PO lui-même n'a clairement pas le recul suffisant pour se rendre compte des erreurs qu'il contient...
Et, d'une certaine manière, une personne qui viendrait m'avouer qu'elle "ne se tient pas à jour" uniquement par manque de recul permettant de se rendre compte de l'utilité d'un concept -- malgré de nombreux avis motivés émis par des gens qui disposent justement du recul nécessaire pour savoir de quoi elles parlent -- perdrait le respect que je pourrais éprouver "par nature" à son égard à une vitesse sans doute proportionnelle à la fermeté de sa décision
Par chance, je sais aussi qu'il n'y a bien souvent pas que le manque de recul à prendre en compte
"L'allocation dynamique, ça tombera au devoir ?"
Si cela ne tenait qu'à moi, l'allocation dynamique proprement dite (à coup de pointeur nus et de new) pourrait être relayée dans la catégorie des "choses à voir s'il nous reste un peu de temps, histoire que l'étudiant ne soit pas surpris par du code ancien"...
Après, j'ai bien conscience du fait que beaucoup de bibliothèques d'utilisation courante ont encore recours à la "méthode ancestrale", ne serait-ce que à cause de leur histoire. Je me doit donc -- en toute honnêteté -- d'admettre qu'il est sans doute préférable qu'un étudiant ait déjà abordé l'allocation dynamique de la mémoire avant de se frotter à ces bibliothèques.
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Bonjour à tous, je n'aie pas suivi tout vos commentaire mais j'ai pu comprendre que certain livre était obsolète en c++ j'aimerai savoir si le livre que je possède est toujours d'"actualité ou obsolète aussi car je ne voudrais pas apprendre quelques chose que je devrais désapprendre et perdre mon temps inutilement à savoir que j'ai déjà pas mal avancé dans ce livre. je vous remercie donc de bien vouloirs m"éclairer sur le sujet. (et ci mon livre n'est pas bon quelle livre pourriez vous me conseillez en Français Svp car je ne lis pas l'anglais) Merci.
Le livre en question est le suivant :
Le langage C++ Initiez vous à la programmation en c++ de Jesse Liberty, Bradley Jones Et siddharta Rao
édition revue et complétée par Olivier Engler Edition Mises à jour avec la norme c++11. de chez Pearson.
C'est globablement un livre qui n'est pas top, une critique pertinente :
Critique du livre par la rédaction Luc Hermitte le 9 décembre 2013
A la lecture des chapitres disponibles gratuitement chez amazon, ce livre semble suivre une approche historique de la présentation du C++. Il présente également diverses erreurs (détails). Certaines sont des raccourcis, faux, mais guère dommageables. D'autres risquent de donner des mauvaises habitudes.
Bien que mise à jour, il ne fait que vaguement aborder le C++11 en sachant que cette "nouvelle" norme change complètement la manière de programmer en C++.
En Français, en bouquin, c'est la dèche.
Reste le cours "under construction" de Guillaume Belz
Oui je sais mais l'anglais est prévu aussi mais pas pour tout de suite...
C'est pourtant une occasion inespérée de s'y mettre : tu as des textes, et une excellente raison pour les lire.
Faut se dire que c'est de l'anglais technique et rédigé (normalement) dans un style pédagogique pour en faciliter la lecture. C'est pas de la poésie anglaise médiévale.
Tu peux aussi te dire que si tu essaies d'apprendre l'anglais pour apprendre l'anglais, ça ne marchera pas. Par contre avec une bonne raison pour l'apprendre, ça ira tout seul, d'autant que l'anglais technique n'est pas d'une complexité diabolique
On t'a expliqué qu'il te donnait des bases pour aller probablement dans la mauvaise direction (la programmation C++ à l'ancienne).
Mais tu fais comme tu veux en fonction de ton avis à toi qui ne connais ni le C++ ancien, ni le C++ moderne, ni la différence entre les deux, c'est toi qui vois.
- Edité par michelbillaud 20 septembre 2017 à 12:11:38
Il donne les bases pour aller dans le mur. Le C++ moderne offre quelques bricoles pour simplifier le code, mais sur le fond, rien n'a changé. En C++ à l'ancienne, les contraintes (que le cours d'OC ignore totalement) étaient les mêmes, le C++ moderne, ne les a pas introduites, il ne les a pas non plus effacées, il les a simplement rendue plus facile à respecter. Il y a par ailleurs un problème de logique, on te dis que le meilleur cours disponible à ce jour n'est disponible qu'en anglais, et que pour un programmeur l'anglais est absolument incontournable. A ta place je me dirais: Ok je veux apprendre le C++, problème toutes les ressources de valeur disponibles sont en anglais et je ne connais pas l'anglais, conclusion logique, je commence par apprendre l'anglais, puis lorsque mon niveau en anglais est suffisant,je passe au C++.
Le nous pourrait être perçu comme un argument d'autorité et c'en est un, la plupart de ceux que j'inclue dans ce nous ont un lien professionnel avec C++, pour certains, comme moi, c'est carrément notre métier, d'autres sont professeurs, et si nous ne sommes pas d'accord sur tout, il y a trois sujets sur lesquels il y a un vaste concensus:
La maîtrise de l'anglais est un pré-requis
Le bouquin de Lippmann est le meilleur cours de C++ accessible.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Discord NaN. Mon site.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C