Bonjour,
Je programme en C et je me suis penché sur le C++ depuis peu. J'avoue qu'au premier abord j'ai trouvé très séduisante cette façon de structurer les  programmes avec les classes, les methodes et les attributs. Une nouvelle façon de voir et de structurer un programme  
Mais en entrant un peu plus dans le code , j'ai trouvé beaucoup de similitude avec le C (struct en c pour les classes en C++)et je me dis que c'est beaucoup de complication et j'ai l'impression qu'on peut vite arriver a une usine a gaz. Le C me semble plus direct et moins contraignant.
Attention ce n'est qu'une première impression sachant que ma connaisse du C++ reste tres limitée. Mais une 1ere impression qui m interroge sur la nécessité d'aller plus loin dans l'apprentissage du C++    
qu'en pensez vous ? vos retours d'experience sur le C++ ?
Merci encore

ce titre  

 
Oui, ca donne l'idée du parti pris
 
Bref ... Pour en revenir au post initial :
Cette façon de structurer dont tu parles est un des paradigmes que tu peux utiliser en C++. L'avantage de C++ est que tu peux mixer ces paradigmes, trouver celui qui s'applique le plus aisément à la résolution de ton problème.
 
Si tu trouves des similitudes avec le C, c'est normal, elles sont volontaires. Ca apporte une facilité de transition de C à C++. Tu convertis les quelques incompatibilités entre les deux langages, et ensuite, tu peux commencer à utiliser les avantages de C++ sur ton programme.
Ca, c'est une approche ... Et ce n'est probablement pas celle qui est recommandée pour un débutant qui souhaiterait se former au C++.
 
Il y a bien trop à couvrir pour t'en donner une idée, mais C++ permet de faire de la programmation générique (jette un coup d'oeil aux conteneurs de la STL par exemple) y compris sur les algorithmes (de même, tu peux regarder ce qui est proposé par le header algorithm)
 
Au final, vu que tu demandes des retours d'expérience ... C++ permet de faire tout ce que C peut faire. Par contre, C++ te facilite la vie quand tu veux manipuler des concepts plus abstraits et malgré tout sans compromis sur les performances. Je trouverais personnellement très frustrant de devoir revenir sur du C.
 
Maintenant, la question : tu dis que tu programmes en C ... Quelle expérience as-tu dessus et quelle ambition as-tu pour la suite ? Parce qu'aussi flexible soit C++, ce n'est pas pour autant le meilleur outil pour faire tous les programmes que tu pourras vouloir

J'abonde sur le post de theshockwave.  
 
En fait en première approche, le C++ semble seulement apporter la vision "objets", mais tous les types de programmes n'ont pas besoin d'une telle souplesse ou manière de structurer un programme.
 
Néanmoins, il est réducteur de ramener le C++ à de l'objet seulement :
- il revoit fortement la notion de type de donnée et des notions de cast
- une des conséquence positive du monde objet est la notion de destructeur et limiter au maximum l'utilisation des pointeurs (via des références) : si bien utilisé, on peut s'approcher d'une gestion de mémoire simplifiée
- La notion de template est une tuerie si on commence à l'utiliser à fond et n'est pas limité à l'utilisation de classe/fonction génériques mais aussi faire faire des contrôles/calculs poussés à la compilation (typage fort, compile time assertion,précalculs ...)
- Limite l'utilisation du préprocesseur au maximum (constantes, templates,...), mais le laisse disponible (et je trouve que ça manque au Java par exemple)
- Les exceptions (surtout associés à la non utilisation de pointeur/destructeur)
 
Après je n'ai jamais utilisé que du C++ "normal" (98) mais j'ai l'impression que le C++11 apporte aussi quelques trucs bienvenus (amélioration contructeurs, ...)
 
Ce que j'adore dans le C++, c'est la joie de laisser faire faire un maximum de chose au compilateur là où il faut tout écrire à la main en C (au dépend de temps de compilation qui explosent surtout dans les optimisations maximales, il est vrai)
 
Mais ce n'est pas un langage que l'on peut facilement dompter/apprécier car les solutions qu'il apporte nécessitent une bonne expérience de programmation sur de multiple langage pour être appréciés/compris

 
Je ne voulais pas entrer dans les détails à ce point là, mais je ne peux que t'appuyer à mon tour.
 
Pour C++11, les lambdas sont tellement pratiques que je n'ai plus envie de m'en séparer. Il apporte aussi des trucs massifs genre la notion de thread et d'atomicité directement dans le langage. Ca a des implications énormes.
Tu parlais aussi de gestion de mémoire simplifiée, C++11 apporte de nouveaux types de pointeurs riches pour expliciter la durée de vie de tes objets (unique_ptr ou shared_ptr) et du coup te passer encore plus de la gestion manuelle de la mémoire.
 
 

Ha, ha, c'est aussi l'impression que j'ai eu lorsque j'ai commencé à étudier ce langage. Mon erreur c'est d'avoir essayé de tout faire par moi même. C'est possible, mais attends-toi à en chier pour des années. Si tu veux t'investir là dedans, je te conseille très très fortement d'acheter un bon bouquin (genre Effective C++): ce bouquin va te montrer quels sont les pièges du langage (et en C++, tu vas être servi), quels sont les aspects moisis à éviter (là encore, avec 30ans d'existence ne t'attends pas à un langage sans aspérité), ceux qui vaut mieux être prudent et à quoi s'attendre lorsque tu combines tout ce petit monde, etc...
 
C'est un des aspects un peu décourageant en C++: le langage est extrêmement vaste. C'est sûr quand on en a fait 8h/jour, 5j. sur 7, pendant 15ans, on a le temps de s'aclimater en douceur à toutes ces évolutions. Mais lorsqu'on débute, on se prends 30 à 40 ans de featuritis dans la gueule, et ça fait mal. La maitrise du langage se paye: compte plusieurs années en solo, pour rester très très gentil. Mais même avec un bouquin, faudra tout de même plusieurs années avant d'arriver à faire autre chose que de la merde.
 
Certains (moi le premier) disent que c'est un peu cher. D'autant que tu pourras probablement pas te contenter d'aprendre les concepts qui t'intéresse et laisser tomber ceux que tu trouves moisis. Parce que toute application en général doit s'interfacer à un moment ou un autre avec le monde extérieur: et là, il y a à boire et à manger. Cela dit ça reste gérable: si vraiment tu dois te farcir un framework moisi, tu peux toujours coller une abstraction par-dessus qui masque l'essentiel du foutoir. Ce n'est pas parfait, certes, mais pour l'avoir fait un paquet de fois, ça reste gérable.
 
Le vrai problème avec le C++, c'est lorsque tu dois travailler en équipe avec un niveau hétérogène. C'est garantie que ça va t'arriver si tu t'investi là dedans. Vu la complexité du langage, il est illusoire d'espérer que tout le monde fera l'effort de connaître les moindres recoins/pièges à con qui te sont tendus par le langage. Ce n'est pas spécifique au C++, mais je trouve que c'est amplifié dans ce langage à cause de la surface gigantesque de ses fonctionnalités: trops de pièges, trop de fonctionnalités qui mène à des voies sans issues, voire dangeureuses (ha, ha, undefined behavior), le coté pointillieux qui fait que si on ne maitrise pas l'aspect on frôle dangeureusement le culte du cargo. J'ai tendance à dire que le C++ dans les mains d'un débutant, c'est comme donner une grenade à fragmentation dans les mains d'un bébé: bien souvent ça te pête à la gueule et il y aura quelques dommages collatéraux sur les personnes au alentour. La dernière version du langage (C++11) mitige pas mal ces problèmes, mais les chances de travailler une telle base de code à l'heure actuelle est quasi nul: si tu reprends un projet, il est plus que certains que tu vas te farcir un passif assez chargé (et l'âge du langage, va pas aider).
 
Le C est effectivement plus facile d'accès, mais la qualité des "frameworks" varient grandement. Moi qui travaille dans le domaine du traitement d'image, trop souvent je dois me farcir la manipulation de bitmap à coup d'arithmétique de pointeur. Par moment, j'aimerais vraiment avoir un truc un peu plus standardisé. Et grâce à ce joyeux foutoir, il m'aura fallu plus de 10ans avant de faire autre chose que de la merde en C/C++: connaître la plupart des pièges, frameworks, outils de la chaine de compilation/débugage, IDE, profilage, etc ... Avec le recul, je trouve ça très cher et quand je vois l'essort de langages comme Java/C#, je comprends tout à fait pourquoi certains ne veulent pas se prendre la tête avec autant de détails.
 
Si tu veux t'investir là dedans, attends-toi à en chier à un moment où un autre, ce ne sont pas des langages qui vont te tenir par la main et où quasiment tout est inclus par défaut, dans un ensemble relativement homogène (genre JDK ou .NET). Quand on sait à quoi s'attendre, en général la pillule passe beaucoup mieux.
 
Voilà pour mes 2¢ d'€ (je devrais dire $CAD, mais ils ont retiré les pièces 1¢ ).

 
Dans certains domaines, tu n'as pas complètement le choix du langage, et ses avantages en terme de performance et d'accès au matériel (faire du SSE en java, ca doit être rigolo) en font un incontournable. (et accessoirement, les compilos officiels pour les consoles next gen supportent la majeure partie de C++11)

Le C est des plus simples.... si tu sais ce qu'est une machine (instruction, mémoire, adresse, ...).
 
En fait je trouve dommage la tendance actuelle qui consiste à confondre abstraction et ignorance.  
 
En fait à chaque langage on a essayé de simplifier tel ou tel aspect du développement/maintenance/portabilité:
- C n'est qu'une simplification de l'assembleur (de plus en plus chiadé certe, mais les fondements restent basiques)
- Java c'est la JVM+"vue objet"+gestion mémoire, etc...
- PHP s'est sa préintégration avec les bases de données et les serveurs HTTP
- Perl pour un mix habile entre C et le scripting shell  
- etc...
 
ça ne me gène de pas de dire : j'ai pris Java/ASP/C# parce que j'avais pas besoin de me faire chier avec ça ou ça. Mais ça se transforme de plus en : je ne sais même plus ce que c'est "ça ou ça" (pointeur, allocation mémoire, appel système, ...). Le C est une école de la rigueur et ce n'est pas un mal en soit. Maintenant ça ne veut pas dire que tout doit être développé en C car c'est "le meilleur langage", loin de là.
 
Je trouve cette dérive inquiétante car pas mal de gens sont trop "scotchés" à leur langage d'origine sans voir ailleurs ni même connaitre ce qui est manipulé et la variété des existants (au moins en avoir conscience) et surtout la notion d'avantage inconvénient de chaque langage en fonction du problème à traiter...
 
Qu'un scientifique/financier qui fasse du dev ne souhaite pas/n'est pas à ce faire chier avec ce que c'est qu'un ordinateur (mémoire, pointeurs, portabilité, ...), c'est normal le programme/langage n'est qu'un outil, son expertise est ailleurs.  
 
Mais qu'un développeur finisse par oublier les "fondamentaux" car en dehors des 3 cours (ASM/C/...) qu'il a eu dans son cursus, il n'a jamais eu à s'en "servir" réellement pour "voir" les différences (et autres avantages/inconvénients)... Après il ne faut pas se plaindre que des chefs voient dans les développeurs des "pisseurs" de code (ce que je déplore car ce n'est pas vrai). Mais pour moi cette "perte" (en moyenne) de ces compétences techniques est un frein à l'évolution du métier et peut-être une part de la perception  
 
Mais je dois être un vieux con réac qui va contre le changement

 
On va pas dériver en guerre des langages, y'a déjà assez eu de débats stériles.
C et C++ ont la même vocation avant tout : permettre de rester proche du matériel tout en écrivant du code cross-platform (tu peux te brosser avec ton assembleur pour faire directement quelque chose qui fonctionne sur PowerPC et sur x86)
 
Et en se limitant à une comparaison entre ces deux langages, je ne vois personnellement aucune raison de se cloisonner au C.  

Pardon je crois que je n'ai pas été clair : je ne voulais surtout pas faire une guerre des langage mais plutôt dire :
- tous les langages ont des avantages et inconvénients
- plus on a appréhendé de langages différents plus on a conscience de ces éléments
- plus on en a conscience plus peu faire un choix "sain" (au sens réfléchi) du bon langage pour le bon problème
- je trouve dommage que cette exploration de nouveau langage ne soit pas plus développé chez les développeurs en général car ça tirerait l'ensemble de la communauté vers le haut
 
PS: je suis assez d'accord que vu que 99% des plateformes ont, via la même chaine de dev, accès à du C et du C++, pas de raison de ne pas "lorgner" du coté du C++

le C++, c'est le C sans la prehistoire de la gestion manuelle et hasardeuse des ressources. C'ets le langage phare pour les infrastructures.
 
Limiter le C++ a l'objet, c'ets comme penser pouvoir tirer un coup en utilisant un seul testicule. C'ets assez ininteressant.
 
L'approche multiparadigme de C++ permet d'adapter le langage au probleme plutot que d'essayer de faire rentrer des ronds dans des carrés. C'ets sa puissance primordiale.

C'est exactement ça.
Dans une équipe hétérogène (ou pas, mais c'est quand même la majorité des cas), je ne connais que la revue systématique de code ou le passage automatisé d'outils d'analyse statique qui permet d'éviter que ça parte complètement en couille.

 
Oh oui ça! Entre ceux qui écrivent tout en templatisant et ceux qui refusent la stl parce que ya des bug sous unix   ça rend les choses pas simples

Bonjour,
 
En fait, tout dépend de ce que vous voulez faire en programmation.
 
Souvent, un code linéaire en langage C fonctionne très bien sans qu'il y ait besoin d'utiliser les classes.
 
Beaucoup de logiciels tournent encore très bien en C.