Apprendre le C++ (quand on connait le C) - C++ - Programmation
Marsh Posté le 24-04-2007 à 02:48:19
A éviter (éviter tout ce qui est en français en C++)
Lire le Stroustrup.
Marsh Posté le 24-04-2007 à 09:16:29
marctes a écrit : A éviter (éviter tout ce qui est en français en C++) |
Mais il est dispo en français le stroutrup
Lit un cours d'objet d'abord (y'a plein de bouquins dans les librairies ou sur le net), un bouquin de design pattern (GoF) quand t'auras compris l'objet, et code toi des exemples au fur & à mesure des lectures (ou sur un projet, carrément) en c++ en ayant le stroutrup effectivement à portée de main par exemple. ou google.
Marsh Posté le 24-04-2007 à 09:18:36
ReplyMarsh Posté le 24-04-2007 à 10:23:01
marctes a écrit : A éviter (éviter tout ce qui est en français en C++) |
Le cours de Bruno garcia est néanmoins assez bien fait
Marsh Posté le 24-04-2007 à 16:30:56
merci pour toutes vos réponses !
j'ai regardé le lien KarLKoX, ne m'en veux pas mais ça m'a pas l'air génial, car je voudrais un cours solide pas juste avec des recettes. Mais je te remercie bien quand meme
C'est quoi le stroutrup ? une sorte de K&r pour le c++ ?
Marsh Posté le 24-04-2007 à 16:33:07
En fait, c'est pas les bouquins qu'il faut éviter, mais la langage
Marsh Posté le 24-04-2007 à 16:33:41
ReplyMarsh Posté le 24-04-2007 à 16:38:54
Par ailleurs, est-ce que vous auriez un projet à me recommander pour exploiter a fond les concepts de POO ?
merci encore
Marsh Posté le 24-04-2007 à 16:55:53
Euh, pour le Stroustrup, il vaut mieux éviter la version française, qui contient (ou espèrons "a contenu" ) des kilos d'erreurs (et c'est pas moi qui le dit, c'est quelques personnes que je suppose suffisamment connaisseurs sur les newsgroups).
Mais pour débuter, je trouve ça quand même costaud, TICPP est quand même plus recommandable comme entrée en matière
Pour un projet à te recommander, c'est chaud, faut voir tes centres d'intérêts
Marsh Posté le 24-04-2007 à 18:04:59
IrmatDen a écrit : Euh, pour le Stroustrup, il vaut mieux éviter la version française, qui contient (ou espèrons "a contenu" ) des kilos d'erreurs (et c'est pas moi qui le dit, c'est quelques personnes que je suppose suffisamment connaisseurs sur les newsgroups). |
merci je vais voir TICPP car le Stroustrup fait pas loin de 1000 pages .... Est ce que ces références traitent du concept objet ou uniquement de la programmation C++ ?
sinon mes centres d'interêts ...heu tout je dirait ? Je voudrai faire un projet qui me permette de débuter en faisant un tour d'horizon pour etre opérationnel, disons avoir niveau moyen en C++, connaitre les classes virtuelles, abstraites, les champs privés publiques et les templates. Et les designs patterns, je ne sais pas si c'est important?
merci
Marsh Posté le 24-04-2007 à 18:17:48
in_your_phion a écrit : Par ailleurs, est-ce que vous auriez un projet à me recommander pour exploiter a fond les concepts de POO ? |
tu dois pouvoir trouver des sujets sur le net : site de certains IUT... etc... si tu trouves pas je te passe mon dernier sujet, et tu me le fais pour ....disons le ... 5 mai ?
Marsh Posté le 24-04-2007 à 18:25:20
Commence par les exos du TICPP alors; et tu te trouveras un projet assez rapidement tout seul
Dis toi simplement qu'un grand nombre de chose peut être vu de façon objet.
Pour le point des DPs, oui, c'est important, mais commence par bien comprendre l'approche objet, tu n'en profiteras que mieux.
BTW, il y a dans la section cours de Developpez.com quelques docs sur l'approche objet; je ne les ais pas lu par contre, mais en première approche ça peut être bon.
Marsh Posté le 24-04-2007 à 21:54:24
in_your_phion a écrit : merci je vais voir TICPP car le Stroustrup fait pas loin de 1000 pages .... Est ce que ces références traitent du concept objet ou uniquement de la programmation C++ ? |
TICPP parle beaucoup d'objets, mais c'est un peu obligé vu le sujet... Mais ce n'est pas un cours de conception objet, loin de là, je trouve.
in_your_phion a écrit : Et les designs patterns, je ne sais pas si c'est important? |
J'ai beaucoup aimé le bouquin de Gamma, Erich, Helm et Johnson. C'est "important" à mon avis car cela montre que la POO ce n'est pas juste connaître la définition d'une fonction virtuelle pure en C++, mais aussi de la saine conception. Très complémentaire du TICPP je pense, à lire après pour comprendre.
Marsh Posté le 28-04-2007 à 22:59:12
boulgakov a écrit : C'est "important" à mon avis car cela montre que la POO ce n'est pas juste connaître la définition d'une fonction virtuelle pure en C++, mais aussi de la saine conception. Très complémentaire du TICPP je pense, à lire après pour comprendre. |
Les design patterns ca rend le code impossible a maintenir...
Marsh Posté le 29-04-2007 à 10:17:36
jojolepingouin a écrit : Les design patterns ca rend le code impossible a maintenir... |
pardon ? des exemple slà : soit je comprends pas "maintenr" soit tu comprends aps "design pattern"
Marsh Posté le 29-04-2007 à 11:28:49
jojolepingouin a écrit : Les design patterns ca rend le code impossible a maintenir... |
C'est juste le contraire.
Marsh Posté le 29-04-2007 à 11:58:59
jojolepingouin a écrit : Les design patterns ca rend le code impossible a maintenir... |
on a récupéré kadreg \o/
Marsh Posté le 02-05-2007 à 22:06:21
Joel F a écrit : pardon ? des exemple slà : soit je comprends pas "maintenr" soit tu comprends aps "design pattern" |
Bon on va partir du principe que je sais ce que sont les designs patterns (je te laisse deduire la suite).
Les designs patterns n'ont pas d'implémentation type (a part peut etre le singleton), ca signifie tout d'abord qu'il faut reconnaitre qu'il y a des design patterns dans le code que l'on a sous les yeux.
* Faciles a reconnaitre:
- singleton, visiteur, commande, factory.....
* Plus difficiles:
- constructeur virtuel, composite, strategie....
* Tres difficiles:
- n'importe lequel quand on commence a le melanger avec plein d'autres.
Ensuite, le code d'implementation du design pattern est souvent foireux (singleton pas thread-safe, factory qui leak...): il y a des bibliotheques qui permettent de faciliter le boulot (ferris-loki, boost...) mais on peut pas forcément les utiliser (essaye de compiler boost avec un compilo HP aCC).
Bref, le secret du code maintenable c'est du code _simple_, les bouts de code charges de design pattern ne font pas partie de cette categorie.
Jojo
Marsh Posté le 04-05-2007 à 23:45:10
et les commentaire, c'est pour les chiens ?
et la communication dans une équipe ?
Marsh Posté le 05-05-2007 à 09:18:21
jojolepingouin a écrit : |
Aprés si tu travaille avec des gens qui savent pas coder, autant arreter de suite et faire de l'ADA structurée ...
Faire une fatcory qui leak faut en vouloir ... idem pr le singleton pas safe ... Le fait que *certaines* personnes ne savent pas écrire des DP correctmeent n'invalide pas leur utilités.
jojolepingouin a écrit : |
En outre
jojolepingouin a écrit : |
Tu as aussi le droit de travailler avec des outils du XXIe siècle ...
jojolepingouin a écrit : |
Le secret du code maintenable, c'ets la communication entre développeur + une bonne dose de commentaires, de test unitaires et de non-regressions.
Après, chacun sa méthode, mais je n'échangerais pas un baril de DP contre un baril de méthode X
Marsh Posté le 13-05-2007 à 17:55:44
Citation : Aprés si tu travaille avec des gens qui savent pas coder, autant arreter de suite et faire de l'ADA structurée ... |
Helas je ne choisis pas les gens avec qui je travaille, je ne choisis pas le langage, et le materiel non plus. Si tu peux le faire, je te félicite (et t'envie meme un peu)...
Ensuite si tu admets que *certaines* personnes ne savent pas écrire de design pattern, tu as l'air de penser que tout le monde peut les comprendre et les modifier (maintenance, nouvelles fonctionnalités...), c'est pas si évident que ca.
Et puis comme tu dis, chacun sa méthode, la mienne c'est de recevoir regulierement un gros baril de vieux code a maintenir quand il n'y a plus personne qui sait comment ca marche et d'essayer de s'en sortir quand meme (appelons ca un baril de methode X...).
Marsh Posté le 13-05-2007 à 18:34:36
jojolepingouin a écrit : |
Je compatis
jojolepingouin a écrit : [quote] |
J'ai donné de ça pendant un moment, après faut juste pas généraliser
Marsh Posté le 16-05-2007 à 18:12:31
Joel F a écrit : J'ai donné de ça pendant un moment, après faut juste pas généraliser |
'Keep It Simple, Stupid'
http://en.wikipedia.org/wiki/KISS_principle
Je dois pas etre le seul a généraliser.
Marsh Posté le 19-05-2007 à 09:21:48
Les design patterns complexes doivent, comme toute complexité, être localisés, voire encapsulés, c'est certains. Ca ne veut pas dire qu'ils ne doivent pas être utilisés. Le KISS, c'est le soucis de découpage en problèmes et structures de données simples (diviser pour régner) et donc d'encapsulation. Une fois ce principe réalisé, le design pattern est facile à documenter (et DOIT l'être nommément) par des commentaires et de la doc d'architecture. S'il y a un leak par-ci, un bug par là, ça n'est pas un problème à partir du moment où le code est encapsulé, ça se corrige.
Après, si un design pattern traverse toute l'architecture d'un logiciel, ta remarque a un certains fondement. Et de toute façon, les DP doivent être utilisés judicieusement et parcimonieusement.
Marsh Posté le 19-05-2007 à 15:05:50
el muchacho a écrit : Les design patterns complexes doivent, comme toute complexité, être localisés, voire encapsulés, c'est certains. Ca ne veut pas dire qu'ils ne doivent pas être utilisés. Le KISS, c'est le soucis de découpage en problèmes et structures de données simples (diviser pour régner) et donc d'encapsulation. Une fois ce principe réalisé, le design pattern est facile à documenter (et DOIT l'être nommément) par des commentaires et de la doc d'architecture. S'il y a un leak par-ci, un bug par là, ça n'est pas un problème à partir du moment où le code est encapsulé, ça se corrige. |
J'ajouterais : un design pattern sert à résoudre un problème particulier en se servant de l'expérience des gens qui l'ont déjà résolu de la meilleure manière du point de vue de l'élégance, l'évolutivité, l'encapsulation, la réutilisabilité, la simplicité etc etc. Quand on parle de DP, ce n'est pas pour dire : "il faut mettre des bouts de DP dans ce programme, c'est à la mode !", c'est pour signaler que pour beaucoup de problèmes de conception identifiés, et souvent complexes, on connaît déjà la meilleure solution à tout point de vue et que cela mérite d'être su.
Et évidemment qu'à tout problème il faut appliquer la solution la plus simple possible, je ne vois pas en quoi il y a contradiction.
Marsh Posté le 20-05-2007 à 10:56:33
boulgakov a écrit : |
Marsh Posté le 21-05-2007 à 09:50:30
Citation : Et de toute façon, les DP doivent être utilisés judicieusement et parcimonieusement. |
Marsh Posté le 23-04-2007 à 15:52:03
Bonjour
J'aimerais m'initier aux joies de la programmation en C++ !! Je "connais" assez bien le C (pointeurs, structures, etc) et j'ai déjà codé des projets conséquents (enfin relativement conséquents ). Auriez vous une référence à me conseiller pour débuter ? Un projet pour me faire la main. J'aimerai surtout être opérationnel au niveau de la POO et des classes (virtuelles, abstraites, notion d'héritage et de polymorphisme etc). Aussi, combien de temps pensez vous qu'il me faudrait pour être "crédible" ?
Merci par avance
Message édité par in_your_phion le 23-04-2007 à 15:52:45