Le C++ en perte de vitesse ?

Salut,

Pour être aussi passé par l'école d'ingé (ensimag), j'ai eu l'occasion de bouffer du c++ en cours et en projets. Niveau enseignement je dois dire que parmi les profs que j'ai eu, c'était pas mal, certains profs avaient le "the design and evolution of c++" implanté dans le cerveau :mouarf:
Après il faut bien le dire, apprendre un tel langage ça se fait pas en 6 mois, si on regarde les autres matières, les autres projets... je comprends qu'une école rechigne à mettre ça au programme car ça demande un gros investissement de temps relativement à d'autres langages si on veut pas envoyer les élèves dans la nature avec un niveau merdique (est-ce que merdique est mieux que rien du tout ? il faut la mériter sa ligne "C++" sur son CV :mrgreen: )
(enfin rien n'empêche de compenser par d'autres matières et de faire bosser son binôme).
Enfin quand je regarde certaines parties du codes source de boost ou Qt, je me sens encore un peu novice...

Même si c'est le le langage que j'utilise le plus (je dois dire que son côté "toujours quelque chose à découvrir" est assez plaisant pour le geek que je suis), je suis quand même bien d'accord (à part les parties un peu agressives :mouarf: ) avec la fameuse intervention de Linus Torvalds sur le C++. Même en se faisant chier à compiler avec du -Wall -W -Wextra -std=c++98 -pedantic, sur un gros projet on se retrouve toujours avec des emmerdes quand on change de plate forme, de version du compilo ou autres. Et ne parlons pas de boost, qui m'a valu de bonnes emmerdes. Après, bien sur, au niveau "génie logiciel", la conception et les possibilités de ces bestioles sont très attirantes à un temps t et sur une machine m et ça permet de faire des choses souvent très élégantes. Mais ce genre d'emmerdes est pas quelque chose que l'on retrouve dans tous les langages, dans mon expérience, C++ est quand même assez propice à ça.
M'enfin ça m'empêche pas d'en faire, au contraire, et le pire c'est que j'aime ça

Aladore> Oui, ya des bindings CUDA pour Java, ça s'appelle JCUda mais ça. M'enfin je reste sceptique quand j'entends "CUDA" et "Java" dans la même phrase, bien que je soie un fervent défenseur de Java pour une certaines classe d'applications. J'imagine que ça doit empêcher d'utiliser ne serait-ce que des templates pour tes kernels... ? (et on se retrouve à dérouler les templates à la main comme avec OpenCL :aie: )

Citation:

---

Même en se faisant chier à compiler avec du -Wall -W -Wextra -std=c++98 -pedantic, sur un gros projet on se retrouve toujours avec des emmerdes quand on change de plate forme, de version du compilo ou autres. Et ne parlons pas de boost, qui m'a valu de bonnes emmerdes.

---

Quel genre d'emmerdes ?

Ma dernière en date, c'est avec boost::serialization
Bon, déjà, le format des archives binaires de boost::serialization n'est pas portable à 100% (à cause des flottants qui sont extrêmement dépendants de l'architecture), mais bon ça j'étais prévenu, c'est écrit noir sur blanc dans la doc.

Bref, j'écris mon appli (un logiciel de simulation numérique de l'ordre de 30K lignes), je compile sur plusieurs machines avec des configs complètement différentes, pas de souci.
Je passe sur le supercalculateur qui a une version plus ancienne de boost, et echec, à cause des mainteneurs qui ont changé certains choix de conception entre les versions au sujet du tracking des types (ils l'ont changé en mieux au moins ;) ). Résultat, ajout d'un "BOOST_CLASS_TRACKING" comme une belle verrue dans le code.
Tout ça me fait penser à la petite controverse qu'il y a eu lors du changement de l'API Nouveau dans le noyau Linux, c'est pas tout à fait le même cas de figure, mais les arguments sont les mêmes.

Autre emmerde : je me suis aussi retrouvé sur une config avec gcc 4.3 et boost compilé avec gcc 4.4. A priori rien de gravissime (?) mais erreur de link entre boost et la libstdc++ quand on utilisait ... merde, une feature dont je ne me rappelle plus...
La il se trouve que ce n'est pas la faute à boost. Enfin, du point de vue utilisateur, ça ne change rien au fait que "si ça ne marche pas à cause d'une librairie, il faut en changer", c'est bête mais c'est comme ça...

Petit quote de la doc de boost :
"However, due to compiler/library quirks and or bugs, some tests fail with some combinations of compilers and libraries. "
Ce n'est donc pas de leur faute, pourquoi pas.
Mais au final, c'est bien là qu'on paye la complexité du langage, c'est que son support ne peut pas être parfait sur toutes les configs. Quand ta contrainte est que ton code doit passer par une validation officielle (qui coute extrêmement cher) et tourner une dizaine d'années sur de multiples configs, au final tu finis par jeter ce genre d'outils à la poubelle et tu contractes le "syndrôme NIH". La ou tu voulais utiliser une belle librairie comme boost qui est reconnue pour sa qualité (et j'en suis le premier défenseur, cette lib est vraiment "magnifique" sous certains aspects), tu finis par te rendre à l'évidence que ce n'est pas acceptable à long terme. Adieu la magnifique et transparente prise en charge de la sérialisation que boost me proposait. Et si en utilisant des outils qui sont sortis dans une fourchette de 1 an et demi on a déjà des ennuis, alors sur une fourchette de 10 ans ça donne des frissons !
D'ailleurs, en lisant les releases notes de boost, quand on voit toutes les emmerdes qu'ils ont pour que leur lib soit compilable partout, on se dit que si personne ne la maintient, dans 2-3 ans ça ne compile plus nulle part :/

A côté de ça, on a des logiciels écrits dans des langages que plus personne n'utilise aujourd'hui et complètement obsolètes, mais qui ont passé l'étape de validation, et l'épreuve des 30 ans d'ancienneté (véridique), alors que écrits à une époque ou on ne pouvait pas allouer de mémoire sur le tas, d'où des "astuces" impardonnables de dépassement "contrôlé" de pile pour simuler des allocations, un bordel sans nom si je peux me permettre. Aujourd'hui, certains de ces logiciels se sont même fait porter en 64 bits (ça fait peur ? oui...) pour une et une seule raison : ça tourne absolument partout. Par contre, si tu lances valgrind dessus, il est déconseillé de rediriger la sortie vers le disque dur :mrgreen: Il faut avoir le coeur bien accroché quand on aime la "belle" programmation !

Bonsoir,

Citation:

---

Bref, j'écris mon appli (un logiciel de simulation numérique de l'ordre de 30K lignes), je compile sur plusieurs machines avec des configs complètement différentes, pas de souci.
Je passe sur le supercalculateur qui a une version plus ancienne de boost, et echec, à cause des mainteneurs qui ont changé certains choix de conception entre les versions au sujet du tracking des types (ils l'ont changé en mieux au moins ).

---

C'est plus un problème de bibliothèque, non?
Tu pourrais avoir le même problème dans un autre langage que le C++.

Citation:

---

Autre emmerde : je me suis aussi retrouvé sur une config avec gcc 4.3 et boost compilé avec gcc 4.4. A priori rien de gravissime (?) mais erreur de link entre boost et la libstdc++ quand on utilisait ... merde, une feature dont je ne me rappelle plus...

---

Tu aimes le risque! :mouarf:

Citation:

---

Quand ta contrainte est que ton code doit passer par une validation officielle (qui coute extrêmement cher) et tourner une dizaine d'années sur de multiples configs, au final tu finis par jeter ce genre d'outils à la poubelle et tu contractes le "syndrôme NIH".

---

C'est clair, mais tu peut faire face au même problème dans un autre langage.

Citation:

---

A côté de ça, on a des logiciels écrits dans des langages que plus personne n'utilise aujourd'hui et complètement obsolètes, mais qui ont passé l'étape de validation, et l'épreuve des 30 ans d'ancienneté (véridique), alors que écrits à une époque ou on ne pouvait pas allouer de mémoire sur le tas, d'où des "astuces" impardonnables de dépassement "contrôlé" de pile pour simuler des allocations, un bordel sans nom si je peux me permettre. Aujourd'hui, certains de ces logiciels se sont même fait porter en 64 bits (ça fait peur ? oui...) pour une et une seule raison : ça tourne absolument partout.

---

Des noms! Des noms! :mouarf:

Salut ;)

Citation:

---

Envoyé par Aleph69

Bonsoir,



C'est plus un problème de bibliothèque, non?
Tu pourrais avoir le même problème dans un autre langage que le C++.

---

Bien sur, mais pour résumer mon post précédent, je dis juste que ce langage implique des emmerdes à cause de sa complexité qui entraîne un support fluctuant et pas toujours digne de confiance. Les librairies commes boost qui utilisent des features avancées du C++ sont les premières à trinquer, car leurs concepteurs savent tirer parti du langage *tel qu'il est officiellement défini*, et leurs auteurs ne sont pas des novices. Quand on voit le nombre de compilos sur le marché et leur approche souvent personnelle des standards pour certains, le facteur risque est multiplié par la complexité du langage.

Citation:

---

Envoyé par Aleph69

Tu aimes le risque! :mouarf:

---

Perso je ne ferai jamais une telle chose sur mon PC, mais quand ce n'est pas toi qui choisit, hé bien c'est à toi de t'adapter. De toute façon, quelque chose que j'essaie d'appliquer le plus possible est le fameux "test du singe". Si l'admin de l'ordi en question est un orang outang qui fait des choix hallucinants, c'est à toi de t'adapter (et pourquoi pas écrire ton programme en Ook Ook :mouarf: )

Citation:

---

Envoyé par Aleph69

C'est clair, mais tu peut faire face au même problème dans un autre langage.

---

Bien sur, mais cf. ce que je dis plus haut! La première normalisation C++ commence à être ancienne et pourtant tu ne peux pas toujours compter sur une réponse uniforme de la part des compilos et des librairies sur une fourchette de temps donnée. Il y a des plate formes ou ce problème est beaucoup moins présent, et qui sont pourtant moins attirantes que le C++ au niveau ingénierie :/

Citation:

---

Envoyé par Aleph69

Des noms! Des noms! :mouarf:

---

Pas le droit de répondre à cette question malheureusement :/

C++ reste un langage très puissant mais il y a quelques facteurs qui ont contribuer a mon avis a sa perte de vitesse:

- Son passé de 30 ans , et ses débuts ou il était bcp associé a C, et la majorité du code existant c'est du C with Classes.

- Son évolution très lente ,du coté standard et compilateurs

- Le manque de ressources humaines, ou effectivement le C++ est de moins en moins enseigné et pire il est vu comme un cauchemar par les jeunes:)

- la concurrence et la complémentarité d'autres langages (java,C#,python,...)

- la communauté C++ n'est plus active sur le web comme avant, il suffit juste de consulter les blogs de c++, la majorité cessaient leurs post il y a des années,quoi que recement il y avait un grand buzz autour de C0x ou C1x :) , et d'un autre coté la communauté java ou dotnet est trop active.

- au sein même de la communauté C++ il y a plusieurs visions, on a l'impression qu'il y a une guerre entre les C++iens,et le débutant se sent perdu.

- malheureusement les articles et revus de vulgarisation informatiques ont aider a faire comprendre que C++ n'est pas du tout productif, et ces points de vues que souvent non éclairés influencent les décideurs qui n'ont le temps que de lire en diagonal les news des technos.

Bonjour,

je suis tombé par hasard sur ce lien :
http://www.tiobe.com/index.php/conte...pci/index.html

Il me semble pertinent pour la discussion et plutôt intéressant de façon générale.