Discussion :

[Katleen Erna]

Les meilleurs programmeurs sont-ils ceux qui disent connaître C ++ ? Pas si sûr...

L'une des particularité de C++, selon Louis Brandy, est que les programmeurs travaillant avec ce langage se divisent en deux catégories. Ces deux groupes s'opposent frontalement et se considèrent chacun comme le seul ayant raison.

Dans le premier, on trouve les développeurs qui viennent de C, ou d'autres qui pensent maitriser C++ très rapidement. Ce genre d'individu vous dira "je connais C++". Mentent-ils ?

Ce langage peut être vu comme l'ascension d'une montagne. Il y a ceux qui sont en bas et se croient déjà au sommet, et ceux qui ont déjà passé le col. Ceux-là souffrent. C'est la deuxième catégorie de programmeurs : ceux qui en ont déjà vu, et qui se rendent compte de l'extrême complexité du langage. Ce qui amène une certaine frustration sur des centaines de petites choses.

Voici une petite illustration satyrique, toujours de Louis Brandy, des étapes qui précèdent l'arrivée au col :






Source : Le Blog de Louis Brandy

[jaimepaslesmodozélés]

j'adore l'image, surtout le point sur les exceptions

C et C++ sont deux langages qui n'ont de commun que la lettre "C" de leur nom.
Passer de C à C++ demande de s'ouvrir à de nouveaux concepts, ne serait-ce que pour l'approche objet (même si certains MacGyver du C prétendent qu'il est "aisé" de faire de l'objet en C).
Passer de C++ à C demande... hou pinaize, non, il faut être taré pour faire ça. Pour ma part, et cela ne concerne que moi, passer du C++ au C aura été symbole de régression et intense torture (pas de booléen, ni de vrai objet, pas de ci pas de ça... maman qu'est ce que je fais là ?).

C et C++ ont chacun leur domaine d'application, ce sont des langages différents, et prétendre en connaitre un premier parce qu'on pratique un second est une preuve de sa méconnaissance du premier (je vais la noter dans un coin cette phrase ^^).

[yostane]

je ne suis pas d'accord avec l'enchainement des points car il qui peut varier

[Folken Laëneck]

Passer de C++ à C demande... hou pinaize, non, il faut être taré pour faire ça.

C'est pourtant bien souvent ce qui se passe au cours d'une formation en informatique (En tout cas ce fut le cas lors de la mienne).
Les professeurs d'informatiques seraient-ils tous fous ?

[jaimepaslesmodozélés]

C'est pourtant bien souvent ce qui se passe au cours d'une formation en informatique (En tout cas ce fut le cas lors de la mienne)

Idem, d'où le choc (j'aurai du tourner ma phrase autrement, je ne pense pas que passer du C++ ou C soit une mauvaise chose, bien au contraire, disons juste que c'est tout sauf une promenade de santé, un mauvais moment à passer)
Sont-ils dingues... je ne sais pas, en tout cas il semblerait que de l'autre côté de l'atlantique les jeunes apprennent directement Java, C/C++ passant littéralement à la trappe. Leurs profs sont peut être moins fous, même si je ne regrette absolument pas d'avoir "mis les mains dans l'cambouis", au même titre que l'Assembleur et ces autres outils de torture. Mais je n'y retoucherai pas hein, pas fou.

[threshold]

Les professeurs d'informatiques seraient-ils tous fous ?

A croire que oui ....je suis passé du Java a l'assembleur puis du C++ au C aussi ...

[TabrisLeFol]

Il manque un point avant "C with classes".

J'ai honnêtement vu des gens dirent faire du C++ par ce qu'ils utilisent le compilateur C++ et des fichiers en *.cpp ... (*)

Alors oui, ce n'était pas complétement du C, par ce qu'il y avait cout et cin mais tout de même...

Après tout est question de definition, du C est du C++, si on regarde seulement la definition du langage, puisque C++ est un surensemble.

* Cela peut etre des cours aussi.

[laflak]

C++ est un surensemble.

Ca l'a été mais ça ne l'ai plus depuis plus d'une dixaine d'année.

[amaury pouly]

J'aime bien l'image

Passer de C++ à C demande... hou pinaize, non, il faut être taré pour faire ça.

Pour ma part, j'ai commencé par le C++ et une fois que je l'ai bien maîtrisé (c'est à dire longtemps après) j'ai vraiment appris le C. Et çà n'a pas été une régression ! Je suis peut être fou mais j'aime bien C, et puis si on utilise la norme C99 alors une partie des problèmes s'envole (au moins psychologiquement: le type booléen par exemple) et le C++ n'est plus un surensemble.

[tomlev]

Sympa l'image

Perso quand j'ai appris C++ en cours, c'était en fait du C avec des cout à la place des printf

[benzoben]

Déjà, connaitre le C est une gageure. Le problème de ce langage est qu'il est trop permissif et connaitre tous les points sensible du langage nécessite une très bonne expérience.
Ensuite, connaitre les différentes normes qui existent, trouver la doc pour les API c'est encore un autre challenge.
Finalement, connaitre le langage c'est aussi connaitre les options du compilateur et dieu sait que gcc prend des paramètres.

Par ailleurs, C++ ne peut pas être considéré strictement comme un surensemble de C car la syntaxe de C++ est incompatible avec celle du C.

[Invité]

c est un language qui ne vieillit pas, même s'il n'est plus le standard universel qu'il a été. Aujourd'hui les raisons de ne pas confier la gestion mémoire au compilateur objet restent nombreuses. La garbage-collection est certes pratique et fiable mais certaines applis en particulier temps réel embarquées ne peuvent pas s'en satisfaire. L'objet est un concept pour rendre la programmation plus lisible par les humains, l'absence d'objet permet de rester près du hardware. Or ce dernier point peut être décisif, surtout quand vos concurrents ont tous fait de l'objet à garbage-collection et que vous leur mettez trois longueur dans la vue par une gestion de buffers millimétrique. Aucun développement objet ne peut descendre aussi bas et ce choix est irréversible une fois l'appli développée. On peut ainsi annuler des maux apparus avec l'objet et la communication ip comme la latence qui est un "mal moderne".

Quoi qu'en disent les académiques , C++ n'a pas apporté que des améliorations : la gestion de mémoire par blocs, les chaines par pointeurs sont définitivement plus performantes en C mais ôô combien plus contraignantes..
De même , la Marshallisation de la mémoire empèche toute persistance dans les pointeurs qui sont inexportables vers une dll, même en lecture seule car le gc peut se produire à tout moment.
Au final toute approche de mémoire partagée est aventureuse en objet qui favorise les copies et ralentit l'ensemble des programmes

Petit test :
essayer de gérer une file d'attente respectivement
1. en utilisant les Cstring (ou string en .net)
2. en utilisant char *monBuffer;

comparer les résultat

[Médinoc]

Euh... unBonGars, pourquoi parles-tu de GC?
Il n'y en a pas en C++, pas même en .Net quand il est question de types natifs...

Sauf bien sûr, si l'on se met à parler des demi-GC de certaines plate-formes embarquées (je dis "demi" parce qu'ils ne font qu'une seule des deux fonctions de ce qu'on appelle un "GC" à l'époque de Java/.Net), là les ennuis commencent. Mais c'est pourquoi on apprend à penser en handles plutôt que pointeurs...

[Florian Goo]

À mon humble avis, il vaut mieux aborder le C++ à partir de Java qu'à partir du C.

S'il y a un domaine où Java est bon, c'est dans l'enseignement du paradigme objet. Ça donne quelques bonnes pratiques et façons de penser à suivre pour partir du bon pied dans l'apprentissage du C++ (qui restera tout de même difficile).

À noter que les spécifications d'exceptions sont dépréciées dans la version à venir du C++.

[Invité]

Euh... unBonGars, pourquoi parles-tu de GC?
Il n'y en a pas en C++, pas même en .Net quand il est question de types natifs...

Sauf bien sûr, si l'on se met à parler des demi-GC de certaines plate-formes embarquées (je dis "demi" parce qu'ils ne font qu'une seule des deux fonctions de ce qu'on appelle un "GC" à l'époque de Java/.Net), là les ennuis commencent. Mais c'est pourquoi on apprend à penser en handles plutôt que pointeurs...

oui, j'a résumé de façon un peu abrupte. L'objet Cstring reste un type dynamique donc sujet à nettoyage automatique dans un autre thread. Pire : l'objet "pointe" les données ce qui rend impossible la gestion d'un gros malloc rempli de chaines et de structures/unions, qu'on peut ensuite "dumper" sur disque ou copier en une seule fois par memcpy(). La suppression des pointeurs, la "dynamicité" de certains types (string, tableaux,..), la dissimulation des malloc/free dans des procédures "magiques" ont un impact négatif sur la performance du programme et inversement sur les projets qui échappent à d'horribles bugs (gérables mais couteux). Ce qui me chagrine, c'est qu'on présente systématiquement ça comme une amélioration. Egalement quand on dit que les cpu sont tellement rapides qu'on peut se le permettre. Le C permet quand même des performances qui peuvent s'avérer décisives quand le système rétrécit (atom) ou à l'inverse, que le programme grossit (encapsulation de nombreuses procédures dans un évenement redraw par ex.)

Le "vrai" progrès consiste à réécrire une appli pleine de champs de saisie et de boutons en architecture document/vue avec un graphique synthétique qu'on peut manipuler à la souris et qui remplace une page entière de données chiffrées, de lookups et autres validations...
s'il s'agit juste de rajouter encore plus de champs et de boutons , alors on ne change rien.

En d'autres termes, puisque l'atom est un progrès, et que l'approche graphique synthétique est un progrès, c'est toute la culture qui change puisque auparavant, le seul progrès acceptable consistait à dire que les cpu étaient toujours plus puissants et qu'une partie de leur charge était consacrée à faire au runtime ce que le programmeur devait faire manuellement au design time avant... si mon explication n'est pas trop confuse, on voit qu'il y a un changement d'école là et que la recherche de performance n'est peut-être pas réservée aux applications spatiales ou militaires !

Sinon en .net les types managés sont "Marshallés" donc sujets à GC. J'ai surtout utilisé dotNet en managé, quand je dois aller vite, je fais une dll en C

[Florian Goo]

Je sens que ça va vite partir en troll tout ça. Bon tant pis, on est vendredi après tout .

Je partage ta vision critique de la tendance actuelle à faciliter le travail du programmeur au détriment des performances du logiciel produit. Mais je pense que c'est nettement moins vrai pour le C++ que pour Java.

L'avantage du C++ c'est que si l'abstraction te semble trop performancivore, tu peux toujours descendre un cran en dessous pour gérer les choses manuellement lorsque tu en as besoin.

Après, je pense que la STL laisse pas mal de poignées à disposition du programmeur pour que celui-ci puisse contrôler la gestion de la mémoire.
La simple utilisation de la fonction std::string::reserve() (présente pour la plupart des conteneurs de la STL) permet déjà de s'en sortir sans avoir à descendre dans une gestion manuelle complète de l'allocation mémoire (et, je pense, sans perte de performance).

[Florian Goo]

Le petite cerise sur le troll, une citation d'un des commentaires du blog d'où est tiré le graphique :

« C++ makes a good programmer better, and a bad programmer obvious. »

C'est poilu, mais j'adore.

[Invité]

non pas de troll , j'ai dumpé mon trouble, je ne compte pas argumenter plus loin. C'est génial d'utiliser à fond les ressouces des compilos récents, sois rassuré. En revanche sur de gros projets industriels, tout la rétorique mi-business mi-technique devient caducque et on ne trouve pas de compétences capables de faire le poids.
Tu as raison de t'interresser à ce que proposent tes outils, j'ai raison de préférer ne pas entrer dans la rétorique d'un éditeur de solutions. Je veux rester hyper spécialisé , tu préfères toucher tous les domaines et dire que ton outil est universel, tu as raison pour autant que tu ne tombes pas sur un gars comme moi comme concurrent direct, là ma spécialisation ferait la différence mais ça n'arrivera jamais. L'industrie manque de cerveaux aussi pointus que la gestion. Ton seul tord est de penser que ton outil devrait s'imposer dans ma spécialité. Comme si l'existance d'Erik Satie devait aboutir à l'interdiction du Rock'n roll...

[Florian Goo]

Au temps pour moi, je n'avais pas retenu le « temps réel embarqué ». Loin de moi l'idée que le C++ est l'outil universel !

[Médinoc]

Marshalling et GC sont des concepts sans relation.

Marshalling et sérialisation par contre...

Et la sérialisation, c'est justement la solution si tu veux pouvoir copier quelque chose par memcpy() (mais la plupart du temps, il faut ensuite désérialiser avant de pouvoir utiliser les données à nouveau).