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  

cours c++

 
A éviter (éviter tout ce qui est en français en C++)
Lire le Stroustrup.

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.

j'oubliais:
http://forum.hardware.fr/hfr/Progr [...] 6910_1.htm

 
Le cours de Bruno garcia est néanmoins assez bien fait

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++ ?  

oui

En fait, c'est pas les bouquins qu'il faut éviter, mais la langage

euh thinking in c++ c'est pas "de la recette" ...

Par ailleurs, est-ce que vous auriez un projet à me recommander pour exploiter a fond les concepts de POO ?
 
merci encore  

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

 
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  

 
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 ?  

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.

 
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.
 

 
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.

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"

C'est juste le contraire.

on a récupéré kadreg \o/

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

et les commentaire, c'est pour les chiens ?
 
et la communication dans une équipe ?

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.
 

En outre
 

Tu as aussi le droit de travailler avec des outils du XXIe siècle ...  
 

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  

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...).

Je compatis    
 

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.

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.

 
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.