Typiquement, prends le zéro qui cherche un conteneur adapté à ce qu'il veut stocker. S'il ne connait pas les spécificités de chaque conteneur, il ne peut pas faire un choix juste.
Voici, à ce propos, un graphique de developpez.com qui permet de s'aider dans ce choix :
@spider-mario On ne vas quand même pas demander à M@teo21 de traiter chaque conteneur de la STL ! la présentation de std::vector est amplement suffisante, non ?
Pourquoi ne pas utiliser la méthode présenté dans la FAQ C++ DVP ?
Parce que, pour un débutant (qui ne sait même pas ce qu'est la POO), c'est difficile de voire une ligne de code utilisant la résolution de portée et des concepts avancés.
Pour exemple, déjà quand j'ai vu la fonction srand() pour la première fois, c'était dur d'avoir une ligne de code que je ne comprenais même pas ...
Alors demander de ne pas comprendre et de faire confiance par la suite, c'est de la programmation à l'aveuglette, et cela mettrait plus en valeur le statut de débutant du lecteur (ils voient cette ligne de code, et puis ils se disent "Zut, c'est dur comme ça le C++ ? J'arriverais jamais à apprendre tout ça moi !") ...
Je propose une nouvelle amélioration, dans la partie 2, chapitre 11 : Traduire son programme avec Qt Linguist :
Le saviez-vous ? Il est possible d'ajouter un livre (phrase book) contenant un ensemble de phrases déjà traduite dans la langue en question. (*.qph), pourquoi ne pas en parler ?
Parce que en l'occurrence c'est un détail dans un détail. Des détails comme celui-ci on pourrait en ajouter des centaines de milliers (que ce soit sur Qt ou sur le C++). C'est certainement intéressant mais la question serait plutôt : pourquoi en parler ?
Dans le genre amélioration vraiment importante, je verrais plutôt une introduction à QtCreator qui est utilisé par plus de la moitié des programmeurs Qt (selon un sondage sur developpez.com). La console c'est bien mais il faut avouer que QtCreator est pas loin d'être l'outil ultime pour programmer avec Qt. Ca ferait moins peur au débutant pour un résultat équivalent voir meilleur.
Inkamath on GitHub - Interpréteur d'expressions mathématiques. Reprise du développement en cours.
Parce que en l'occurrence c'est un détail dans un détail. Des détails comme celui-ci on pourrait en ajouter des centaines de milliers (que ce soit sur Qt ou sur le C++). C'est certainement intéressant mais la question serait plutôt : pourquoi en parler ?
Il n'y a vraiment pas grand chose à dire sur la traduction, c'est l'un des seuls détails en rapport avec qui n'ait pas été traité, pourquoi pas ?
Citation : iNaKoll
Dans le genre amélioration vraiment importante, je verrais plutôt une introduction à QtCreator qui est utilisé par plus de la moitié des programmeurs Qt (selon un sondage sur developpez.com). La console c'est bien mais il faut avouer que QtCreator est pas loin d'être l'outil ultime pour programmer avec Qt. Ca ferait moins peur au débutant pour un résultat équivalent voir meilleur.
Pourquoi pas ? Mais là, il faudrait mieux envisager un big-tuto à part... Ou sinon, présenter QtCreator (1.3 traduite, et traduction de la 2.1 prévu à la sortie) à la place de Code::Blocks, mais là on se heure à un problème, on fait quoi de la commande system("PAUSE"); chez windows ? QtCreator à l'inverse de VS, et de nombreux autres IDE ne rajoute pas cette ligne de code dans nos programmes console. Et visiblement, l'alternative que j'ai proposé précédemment semble déstabilisé les débutants :
Parce que en l'occurrence c'est un détail dans un détail. Des détails comme celui-ci on pourrait en ajouter des centaines de milliers (que ce soit sur Qt ou sur le C++). C'est certainement intéressant mais la question serait plutôt : pourquoi en parler ?
Il n'y a vraiment pas grand chose à dire sur la traduction, c'est l'un des seuls détails en rapport avec qui n'ait pas été traité, pourquoi pas ?
Oui, "pourquoi pas ?".
Citation : Abdelite
Citation : iNaKoll
Dans le genre amélioration vraiment importante, je verrais plutôt une introduction à QtCreator qui est utilisé par plus de la moitié des programmeurs Qt (selon un sondage sur developpez.com). La console c'est bien mais il faut avouer que QtCreator est pas loin d'être l'outil ultime pour programmer avec Qt. Ca ferait moins peur au débutant pour un résultat équivalent voir meilleur.
Pourquoi pas ? Mais là, il faudrait mieux envisager un big-tuto à part... Ou sinon, présenter QtCreator (1.3 traduite, et traduction de la 2.1 prévu à la sortie) à la place de Code::Blocks, mais là on se heure à un problème, on fait quoi de la commande system("PAUSE"); chez windows ? QtCreator à l'inverse de VS, et de nombreux autres IDE ne rajoute pas cette ligne de code dans nos programmes console. Et visiblement, l'alternative que j'ai proposé précédemment semble déstabilisé les débutants :
Bon en même, il doit y avoir deux gros boutons dans QtCreator. C'est un peu maigre pour un big tuto... L'éditeur graphique est déjà présenté dans le chapitre sur QtDesigner. Il n'y a pas grand chose à ajouter pour introduire QtCreator.
Sinon tu te compliques la vie, system("PAUSE") est un faux problème. Cet argument vient un peu comme un cheveu sur la soupe. Il n'y a pas d'IDE plus simple que QtCreator. Il est utilisé par plus de la moitié des programmeurs Qt, débutants ou expérimentés... Il faudrait trouver une meilleur raison de ne pas en parler.
Edit : Esprit de contradiction quand tu nous tiens...
Inkamath on GitHub - Interpréteur d'expressions mathématiques. Reprise du développement en cours.
As-tu déjà traduis un "gros" programme avec l'aide de Qt Linguist ? Pour te donner une petite idée, regarde les fichiers de traductions de QtCreator. Tu verras que des termes reviennent de manière assez récurrentes, ces livres nous facilitent vraiment les traductions... Ça ne peut être qu'un bonus si on compte diffuser et internationaliser nos programmes...
Citation : iNaKoll
Bon en même, il doit y avoir deux gros boutons dans QtCreator. C'est un peu maigre pour un big tuto... L'éditeur graphique est déjà présenté dans le chapitre sur QtDesigner. Il n'y a pas grand chose à ajouter pour introduire QtCreator.
Oui, si on ne compte pas expliqué tout ce qu'il y a de magique dans Qt Creator... Ça reste un banal IDE comme les autres.
Citation : iNaKoll
Sinon tu te compliques la vie, system("PAUSE") est un faux problème. Cet argument vient un peu comme un cheveux sur la soupe. Il n'y a pas d'IDE plus simple que QtCreator. Il est utilisé par plus de la moitié des programmeurs Qt, débutants ou expérimentés... Il faudrait trouver une meilleur raison de ne pas en parler.
Compile avec QtCreator ce très simple programme en console présenté :
Le plan que M@teo21 à choisie est criticable sur certains points, cependant c'est celui là qu'il a choisi et en changer dedmanderais quand même un gros travail. Le choix de l'approche historique n'est pas forcément le mieux (je n'en suis pas partisant non plus), mais c'est celui-là qu'il à choisi, et je pense que maintenant, il serait plus profitable de corriger et de rajouter quelques éléments dans le cours actuel en conservant le plan que de tout refaire. J'ai pas le cours exact en tête (et pas le temps de le relire), mais de mémoire, à corriger/amélorier, il peut déjà y avoir :
- Intégrer les divers commentaires pertinants (sur les différents chapitres)
(le reste est un avis purement personnel :
- Insiter d'avantage sur la liste d'initialisation (limite ne pas présenter l'affectation dans le corps mais seulement la liste d'initialisation)
- Insiter sur la relation IS-A de l'héritage publique (si je me souvient plus si le privé est présenté, si c'est le cas, il est vraiment superflux pour le tutorial, en comparaison à d'autre chose qui ne sont pas présentées)
- Ne PAS présenter les getters/setters (ca évitera d'en voir partout après)
- Présenter quelques principes de la POO : SRP au moment de l'explication de ce qu'est une classe (ie avoir une seul responsabilité), Encapsulation (ca c'est déjà fait, même si la défintion est "approximative"), LSP (même si sans avoir présenté les fonctions virtuels ca n'a pas trop d'utilité :s) et OCP au moment de l'héritage (sans rentrer dans les détails, juste de manière superflux avec un petit exemple du pourquoi).
- Et un gros problème, soit présenter le mots-clé virtual au moment de l'héritage publique, soit ne présenter aucun des deux, hériter (publiquement) d'une classe dont le destructeur n'est pas virtuel est un UB (à la destruction dans certains cas), présenter quelque chose qui est succeptible de faire n'importe quoi c'est un peu risqué :s
- Présenter le mots-clé const, là question est où l'introduire ?
Après évidament présenter les conteneurs standars, les smart_ptr, boost serait bien, mais ce n'est pas le plan actuel du tuto et les intégrer demanderais un gros effort de remaniement, déjà juste avec les quelques points que j'ai cité (et on peut en trouver d'autre), il y a déjà beaucoup à faire sans changer l'ossature !
NB : Quand je dis présenter les principes de la POO, ca peut-etre sans les citer explicitement, juste en disans ce qu'il faut faire et ce qu'il ne faut pas faire.
@M@teo21: J'essay de faire une critique constructive et ne remets pas en cause tes choix, qui bien que criticables te permettent quand même une bonne pédagogie. J'ai commencé avec tes cours, et je crois que sans eux je n'aurais pas réussi à aller plus loin. Cependant avec le recul et les questions recurrantes posées sur le forum, on se rend compte que certains points sont trop vite abosrdés pour les zéros (const, liste d'initialisation, getters/setters, forme canonique des opérateurs par exemple).
Vous rêvez pas mal j'ai l'impression. Le plan qui a été proposé fait appel sur la lib boost (que je ne connais pas assez) et qui n'est pas du tout présenté dans le tuto actuellement.
Il va très vite sur ce qui est structures de contrôles, ne présente pas les tableaux (oui il y a les vector, mais on ne peut pas faire l'impasse sur les tableaux malgré tout, on y est forcément confronté un jour !).
Il ne parle pas des structures, de la programmation modulaire et même des pointeurs, dont on a toujours besoin (les références ne les ont pas complètement remplacés, loin de là ! Qu'entends-tu par "les vrais cette fois" ? Ceux du C sont faux ?).
Si je dois introduire les pointeurs en C++, je vais devoir... recopier à 99,99% le chapitre issu du tuto de C... et devoir maintenir deux chapitres identiques en parallèle ! Et c'est valable pour pas mal d'autres chapitres !
Est-ce que vous vous rendez compte que ce n'est vraiment pas possible ou il n'y a que moi qui le vois ?
ps : quant à Qt, cela fait partie de la méthode pédagogique qui fait vraiment pratiquer sur le sdz. Si je retire ça, on retombe à peu de choses près sur un énième cours théorique et abstrait où on ne voit pas l'intérêt de ce qu'on apprend, et je ne le souhaite pour rien au monde.
Je trouve qu'on commence à s'égarer complètement, chacun a sa propre idée de ce qu'il faudrait pour un tuto de C++. Et chaque contribution de serialtueur nous fait partir complètement à l'ouest.
+1
Au risque de passer pour un admirateur fanatique, ou pour je ne sais quel autre type d'opportuniste par contact influents, et quand bien même je viendrais à être considéré de la sorte, sachez que je me serais alors épris d'un sentiment de délectation incommensurable tant mes intentions sont tout sauf la recherche de plaire à quelque humanoïde influent que ce soit. En outre, sachez que les idées sont faites pour êtres pesées, débattues et partagées! Disons alors que je suis fondateur d'une religion qui m'est propre et qui m'auto-satisfait: rien ni personne ne pourrait de toute façon rehausser mon statut divin, en effet dans mon institution sectaire dont je suis le seul partisan, toute la divinité se structure autour de la recherche de savoir, d'envie, de motivation et de plaisirs!! Ces mêmes bienfaits de l'humanité que personne d'autre ne peut me procurer!!!! "Il faut cultiver son jardin!"
Ceci étant dit, j'estime que sur ce point M@teo21 a amplement raison, si un zero venait à s'échouer de fatigue ou d'incompréhension sur l'un de ces mémorables tutoriels qui ont déjà permis la réussite scolaire de nombreuses personnes, ou que ce dernier était confronté à multitudes de difficultés relatives à l'identification du langage C en tant que langage procédurale et du langage C++ en tant que langage exploitant la POO, et cela même après une rapide recherche chez un ami nommé Google, alors ce dernier n'a plus qu'à s'assurer de profiter de l'intégralité des facultés mentales requises en ce bas-monde. Ce type d'erreur est en effet le plus souvent dû à un manque d'attention et rien ne pourra y changer quelque chose. Avant de critiquer de façon si agressive, ne vaudrait-il mieux pas avoir sois-même réalisé des tutoriels d'une même qualité...
@lex62 : J'ai pas saisi la moitié de ce que tu as dis enfin passons. C'est vrai qu'on est un peu pour ne pas dire trop, penser à ce que l'intégralité du tutoriel soit repensé, réécrit. Au vu de la réaction de M@teo21 à qui lui seul appartient la décision de prendre en considération nos améliorations, on a tous vite abandonné cette idée... C'est vrai que d'un côté la pratique c'est essentiel, je ne le conteste pas.
Enfin bref, le titre de la discussion n'a pas changé, ici on propose des améliorations sur le cour actuel qui va plus ou moins être maintenue dans quelques mois comme le cour sur Linux actuellement. Si vous avez des suggestions n'hésiter surtout pas. J'en profite pour proposer une petite amélioration, dîtes moi ce que vous en pensez : Pourquoi ne pas parler des classes QCoreApplication (programmes CLI) et QApplication (programmes GUI) un peu plus en détail ? C'est comme QObject, et QWidget un point à ne pas manquer avec Qt.
@lex62 : J'ai pas saisi la moitié de ce que tu as dis enfin passons. C'est vrai qu'on est un peu pour ne pas dire trop, penser à ce que l'intégralité du tutoriel soit repensé, réécrit. Au vu de la réaction de M@teo21 à qui lui seul appartient la décision de prendre en considération nos améliorations, on a tous vite abandonné cette idée... C'est vrai que d'un côté la pratique c'est essentiel, je ne le conteste pas.
Enfin bref, le titre de la discussion n'a pas changé, ici on propose des améliorations sur le cour actuel qui va plus ou moins être maintenue dans quelques mois comme le cour sur Linux actuellement. Si vous avez des suggestions n'hésiter surtout pas. J'en profite pour proposer une petite amélioration, dîtes moi ce que vous en pensez : Pourquoi ne pas parler des classes QCoreApplication (programmes CLI) et QApplication (programmes GUI) un peu plus en détail ? C'est comme QObject, et QWidget un point à ne pas manquer avec Qt.
Si l'on égarait ces quelques idées fantasmagoriques digne des plus grands utopistes , ce topic est une excellente initiative qui vise à améliorer la qualité du tuto de M@teo21. Mais il ne faut pas oublier que seul l'auteur reste maître de sa plume, et c'est après tout, l'essentiel..., le reste n'est qu'illusion!
En ce qui concerne l'idée pour laquelle les classes QCoreApplication et QApplication seraient plus détaillées, j'approuve!
Voilà un sujet que, lorsque j'en ai débuté la lecture, je ne croyais pas qu'il serait aussi intéressant.
Les propositions de iNaKoll et de de passage me semble très intéressantes.
Je ne vois pas de côté négatif à proposer une alternative au tuto de M@théo, pour apprendre directement le C++. Je serais même intéressé à participer au projet (mon niveau en C++ n'est pas non plus suffisant pour y arriver seul, mais je crois avoir des bases assez solides pour apporter mon aide dans un tel type de cours (qui n'est, finalement, qu'une introduction au C++)).
Il resterait par contre quelques discussions à avoir. En effet, le tuto de Nanoc présente, et ce très bien, certaine notions traitées dans la présentation de de passage. Le nouveau tuto serait donc quelque peu redondant (reprenant des concepts présentés partiellement dans le cours de C et dans le cours de Nanoc, en plus du cours C++...)
Je crois qu'il faudrait donc d'abord regarder du côté de Nanoc. Peut-être serait-il intéressé à recevoir de l'aide pour la rédaction de son tuto (qui n'avance que très peu depuis plus d'un an, ce que je comprends tout à fait, mais ce qui me permet de penser qu'un peu d'aide ne serait pas de trop). Ce tuto pourrait alors devenir l'alternative au tuto de M@théo, pour apprendre directement le C++. De plus, cela pourrait nous (nous étant les personnes qui répondent aux questions sur le forum) permettre de donner une référence ou un lien à certains débutant qui viennent sur le forum, confus ou avec des codes en mélangeant le C et le C++ et qui aurait lu le cours de M@théo. Les deux cours pourraient donc même fonctionner ensemble, et se compléter (Le tuto de M@théo pour un incroyable simplicité et toutes ses autres qualités, l'autre cours pour une approche plus directe et plus épuré du C++, admettons).
Et, définitivement, un LdZ pourrait alors suivre. Je crois en effet qu'il serait impensable d'adapter l'actuel cours de C++ en LdZ, ou en tout cas, en tant que "client", j'en serais (sans prétention) insatisfait.
Je comprends que le travail soit considérable, mais vendre un livre, ce n'est plus comme publier un tuto gratuit sur un site web. Dans le sens où, les personnes désirant lire ce livre devront débourser de leur poche un montant. Et demander à de potentiels clients d'acheter, au préalable, un livre sur le C présentant les bases en C pour apprendre le C++ n'a simplement aucun sens à mon avis... Je suis conscient que cela n'est que mon simple avis. Peut-être que je me trompe et que ce livre conviendrait à des milliers de clients, je ne suis pas un spécialiste en la matière. Par contre, je fais partie de la clientèle visée qui n'achèterais pas ce livre, je me dis donc que je ne serais pas le seul acheteur potentiel déçu...
Je considère par contre cette vision un peu idéaliste (que voulez-vous... quand vous l'avez dans l'âme, c'est dur de s'en débarrasser) et je suis conscient des nombreux problèmes relatifs à cette idée, ainsi que des nombreuses idées hypothétiques (notamment au niveau du Tuto de Nanoc ou du LdZ) sur lesquelles se basent mes raisonnements et mes suggestions.
Mais, reste, je trouve le projet très intéressant et je crois qu'il y aurait définitivement quelque chose à faire de ce côté qui satisfasse autant M@théo, les débutants en programmation, les personnes voulant s'initier spécifiquement au C++ et etc.
Ps. M@théo, je ne crois pas que personne ne te mettent la faute directement dessus pour ce qui est de la confusion C/C++. Elle existait effectivement bien avant, la preuve on la retrouve un peu partout sur le net. Seulement, force est de constater, après plus de trois ans à trainer sur les forums C et C++ du site, que tu entretiens cette confusion. Ainsi, je crois que rajouter cette fameuse phrase en introduction, en la mettant bien en valeur, permettrait déjà de faire une petit bout! (Je parle de rajouter que le C++ est très clairement différent du C. À la limite, il y a tellement de messages intéressants à ce sujet sur le forum qu'il suffirait de mettre une citation ou un lien vers un message d'un des "grands" ( ) du forum détaillant la différence entre ces deux langages).
oui tu as raison, mais en général on apprends a programmer pour faire des logiciels avec interface graphique. d'où l'intérêt d'améliorer ses connaissance sur Qt.
oui tu as raison, mais en général on apprends a programmer pour faire des logiciels avec interface graphique. d'où l'intérêt d'améliorer ses connaissance sur Qt.
Bof, perso l'interface graphique rien à faire, ce qui pourrait m'interesser dans Qt (ou autre) c'est les choix effectués par les concepteurs. (l'utilisation d'un god object pour Qt par exemple), et pas le comment afficher une fenetre, ca avec la doc ca passe tout seul et ca ne présente aucunes difficultés techniques.
Concernant les améliorations ponctuelles, je vous invite à consulter mes commentaires pour chaque tuto.
Certains ont été intégrés, d'autres non.
[Ah. De passage en a vus. Très bien]
Concernant des améliorations globales. Je n'ai jamais caché mon désaccord avec l'approche historique. i.e. C -> C++. Ou plus exactement C++ avec C en pré-requis, ou en commençant par voir les incontournables du C avant (i.e. pointeurs, fonctions variadiques). La partie C++ (grep -v Qt, si vous préférez) du tuto de M@teo21 suit l'approche historique à un détail près : il présente std::string au tout début (ce qui très bien). Présenter les vecteurs au même moment serait donc une bonne idée, AMA.
Vous pourrez trouver des exemples d'approche non-historique (parfois qualifiée de moderne -- mais pas du tout au sens meta-prog template) dans les ouvrages:
- Je me Lance par Francis Glassborrow, chez Micro Application, mais en rupture de stock (en faisant le tour des libraires en ligne il doit y avoir moyen d'en trouver un exemplaire, mais lisez avant mes commentaires à son sujet (google!) avant d'investir, il est un peu particulier -> C++ 100% procédural, avec 0% de pointeurs (si! si!), mais exploitant sans vergogne la bibliothèque standard (string, vector, ...), 0-itude du coeur de cible 99% (dame 40-50 ans qui sait allumer sa machine, naviguer et comptable si mes souvenirs sont bons), traduction du CD bugguée, et pour windows initialement). Bref, une étrange expérience, qui est concluante.
- Accelerated C++, par Koenig et Moo, chez Addisson-Wesley, longtemps la référence.
- Programming Principles and Practices using C++, par Stroutrup, traduit chez Pearson depuis la mi-septembre, le challenger.
Même sans investir dans ces ouvrages, leurs tables des matières en ligne sont très évocatrices des approches non historiques.
NB: migrer un cours historique vers un qui ne l'est pas est tout sauf simple, ce sont deux démarches pédagogiques assez différentes. C'est beaucoup de boulot et de motivation. Cela revient à tout recommencer.
..[je finis de lire les posts].... Voilà, très joli post de de passage.
[Par contre, l'alloc dynamique est difficile à contourner avant le polymorphisme je pense. De plus je me demande si les deux familles de classes C++ ne devraient faire l'objet de deux (séries de) chapitres indépendants: la sémantique de valeur (qui accepte la surcharge d'opérateurs, pour laquelle on s'intéresse à la copie, triviale, puis suivant la forme orthodoxe canonique de Coplien (ou dérivée) (déjà abordée dans le tuto, mais sans le terme peut-être bien)), et celle d'entité (qui se passe de copie et de surcharge d'opérateurs, mais qui se mélange avec l'héritage). Par contre, c'est vite théorique, et pas toujours adapté à un discours ludique où les classes de l'une et l'autre famille vont s'entremêler.
]
------------
boost ? C++1x ?
On n'y est pas. Là, ce sont vraiment des choses un peu transverses.
C++1x apportera son lot de modifs qui rendront la prochaine génération de cours C++ à visée des débutant encore plus simple [certains posts me laisse à penser que certains d'entre vous ne diraient pas non à être cette prochaine génération, mais attention, il faut que votre public dispose des outils adéquats pour en profiter.]. Mais on n'y est pas. De plus, je vois mal un public "zéro" être la cible de tels tutos.
Les shared_ptr au moment de l'alloc dynamique peut-être. Je n'ai pas encore d'avis sur comment intégrer le RAII dans un plan (vu que cela présuppose de traiter les exceptions). J'ai cru comprendre que PPPuC++ a encore une nouvelle approche où justement les problèmes ne sont pas ignorés, mais pris en compte tout du long de la démarche. À confirmer.
-----------
@Abdelite
Si l'IDE est bien utilisé il fait la pause de lui-même. Le développeur n'a pas à parasiter le code.
La refonte du tutoriel actuel portant sur le langage C++ et le framework Qt vient tout juste d'être entamé ! L'annonce a été faite par M@teo21 fait à ce sujet via le réseau social Twitter il y a déjà quelques jours. Nanoc, validateur C++, est également dans l’aventure.
C'est pour nous l'occasion de réunir nos suggestions et commentaires à nouveau. Merci pour vos contributions.
1) Parler de la STL
1.1 Templates (nanoc tuto)
1.2 Présenter tous les containers (plus important du moins, list, vector, map...)
1.3 Dans quels cas les utiliser, bien entendu, il est quelque fois mieux d'utiliser une list qu'un vector)
2) Boost
1. Présenter les smart pointers
La refonte du tuto est en cours et avance plutôt bien mais on ne va pas pouvoir tout présenter au fur et à mesure. Là on est en train d'écrire / réécrire toute la première partie du cours pour la rendre standalone, c'est-à-dire ne pas supposer que le lecteur connaît le langage C. C'est un peu fastidieux (on refait des chapitres de base) mais on va bientôt en voir le bout. Dès qu'on aura quelque chose de consistant de prêt, on devrait pouvoir vous montrer ce premier gros bout (d'ici quelques semaines environ on va dire).
Pour ce qui est des chapitres plus avancés, forcément on va s'en occuper après. La STL avec les templates et containers est au programme. Boost ne l'est pas.
Sans aborder boost, vu la date d'arrivée du prochain standard, je pense préférable de tout même aborder quelques nouveautés comme les std::shared_ptr.
A quelles autres nouveautés penses-tu ?
Pour te répondre sur ce point spécifique. On s'est posé la question de l'introduction ou non des pointeurs intelligents. On a finalement décidé qu'on ne le ferait pas pour les raisons suivantes:
Cela ne fait pas encore partie de la norme. Il faut utiliser tr1 pour y avoir accès.
On ne veut pas introduire boost.
Les auto_ptr présents dans la norme actuelle sont à déconseiller.
C'est tout de même un concept assez avancé et présenter des cas d'application simple n'est vraiment pas aisé.
Le cours sera déjà très long.
Au niveau des pointeurs, on a décidé de les introduire le plus tard possible au profit des références pour ne pas voir des pointeurs fleurir partout. Ceci permet de limiter aussi les cas d'utilisation au strict nécessaire.
Maintenant, la partie sur la STL n'est pas encore finalisée en terme de contenu. Peut-être qu'il y aura de la place pour en toucher un mot mais ce ne sera probablement le cas.
Comme l'a dit M@teo21, on pense publier la première partie, le C++ non-OO (mais avec string, vector, etc) prochainement. On prendra volontiers tous vos commentaires.
Sauf que le prochain standard est bientot le courant, donc je ne vois pas le problème qu'il y a à introduire les pointeurs intelligents (peut-etre pas tous, mais au moins shared_ptr), sans compter qu'à moins d'avoir un compilo très vieux (ou sur une plateforme très spécifique, ce qui n'est pas le cas des zéro), ils sont déjà implémentés.
Pour la complexité, une fois introduit la notion de pointeur (disons en même temps que celle d'allocation dynamique), le plus dur est fait. Voir par exemple le tuto de shareman, où il introduit bien la notion et ca reste abordable par les zéros.
Pour la STL (j'entends ici l'ensemble conteneur/iterateurs/algo), je pense que l'important est de montrer qu'elle permet beaucoup de chose, sans pour autant tomber dans un catalogue des algo et conteneur. Pour les itérateur, vous avez prévue de les utiliser dès le début avec les vector (partie non-OO) ou pas ? Je pense que ca serait bien, mais pas des plus évident à intégrer j'en suis conscient.
× 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.
If you'd like to join us, read "How do we work at OpenClassrooms"! :)