Discussion :

[super_navide]

Moi j'aime pas C++ et préfère java pour les raison suivantes :
la syntaxe de java est plus simple.
Le C++ n'a pas de garbage collector.
Le C++ n'a pas d'API de d'introspection comme java.reflect.
Le C++ doit recompiler pour être exécuter sur d'autre plateforme.

Oui C++ est très performant mais au prix d'une complexité importante dans le temps java prendra le dessus mais C++ restera comme le COBOL.
Car aujourd'hui la performance ce sont les carte graphique avec les shaders qui explose n'importe quel programme C++ au niveau performance.

Donc C++ comme COBOL ca existera toujours pour les intégristes qui ne savent pas évoluer vers d'autre langage....

Je pense que java est Le Langage de programmation qui permettra de tous faire dans ses futures versions.

[foetus]

la syntaxe de java est plus simple.

Bof, même si la grammaire du C++ est ambiguë, il n'y pas vraiment de truc tordu.
Juste des fonctionnalités qui rajoutent "une autre forme de coder"

Le C++ n'a pas de garbage collector.

Mais tu peux coder ton propre ramasse-miette. Eugen Systems le fait pour leurs jeux

Le C++ n'a pas d'API de d'introspection comme java.reflect.

Cela se défend. Il y a le RTTI et des vieilles techniques (comme mettre le nom de la classe dans la classe par exemple)

Mais en règle générale, lorsque tu fais cela en C++, cela commence à sentir mauvais pour ton code

Le C++ doit recompiler pour être exécuter sur d'autre plateforme.

C'est même mieux Lorsque tu vois les différences entre les plateformes tu m'étonnes que tu ne puisses pas

Car aujourd'hui la performance ce sont les carte graphique avec les shaders qui explose n'importe quel programme C++ au niveau performance.

Vieux débat entre CPU généraliste (comme les CPUs) et un CPU spécialiste (comme les GPUs)

Et mine de rien, faire un programme full-shader n'est pas possible (ce sont les pilotes qui redirigent le travail si je ne dis pas de bêtises).
Et OpenCL n'arrive pas à décoller

Donc C++ comme COBOL ca existera toujours pour les intégristes qui ne savent pas évoluer vers d'autre langage....

N'importe quoi. Un langage == un domaine d'application.
Tu t'imagines qu'au lieu du javascript ce soit du C++
Et inversement, tu t'imagines coder un logiciel (un truc sérieux) en javascript ou Ruby voire Python

[Iradrille]

Moi j'aime pas C++ et préfère java pour les raison suivantes :
la syntaxe de java est plus simple.

Je te l'accorde.

Le C++ n'a pas de garbage collector.
Le C++ n'a pas d'API de d'introspection comme java.reflect.

Question de point de vu surement, ce sont pour moi les deux plus gros avantages du C++ sur Java.

Le C++ doit recompiler pour être exécuter sur d'autre plateforme.

Tout comme une JVM doit être présente sur toute machine cible pour le Java, mais oui, le fait que le langage ne soit pas multiplatforme est un défaut (il est tout à fait possible d'écrire du code portable cependant).

Car aujourd'hui la performance ce sont les carte graphique avec les shaders qui explose n'importe quel programme C++ au niveau performance.

Tous les algos ne s'y prettent malheuresement pas.

Je pense que java est Le Langage de programmation qui permettra de tous faire dans ses futures versions.

Même une JVM ?

[CodeurPlusPlus]

Vive le C.

[dclink]

35 ans ... Respect !
Je suis (tres) loin d'utiliser toutes les capacites du C++ (une ou deux fois peut etre ai je touche du C++11), tout au plus les STL containers, templates ... A part ca, j'utilise pas mal les fonctions C dans du code C++.

PS : Il me semble qu'il existe des garbage collectors pour le C++ (au moins on a le choix ), n'ayant jamais utilise cela (et n'envisageant surement pas de le faire) je n'ai aucune idee de l'impact sur les perfs.

[AliusEquinox]

Si COBOL est encore numero 1 dans le domaine de la finance, c'est du essentiellement au fait que s'il fallait tout réecrire dans un autre langage comme C++ (ou Java, mais il y a plus de réserve à son égard), le nombre de defaut augmenterait en fleche pendant une periode indéterminée. Se serait evidemment une catastrophe parce que les banques perdraient de l'argent.

De plus, si je puis dire, les developpeurs (tous langages confondus) developpent de plus en plus mal, pour être plus précis, la part des mauvais developpeur augmente considérablement dans la moyenne. Ce qui vous l'aurez deviner pousse les banques -- qui ont une frousse du risque monumentale (déformation professionelle tout ça tout ça) -- à être quelque peu pessimiste à l'égard de certains langages (Java où tu te cache ?! ).
Alors vous comprendrez, je l'espère, le raisonnement des banques : pourquoi utiliser un autre langage alors que COBOL est là ? pourquoi faire confiance a des nouveaux developpeurs alors que les developpeurs COBOL sont là depuis des décennies ?

[Uther]

Tout comme une JVM doit être présente sur toute machine cible pour le Java, mais oui, le fait que le langage ne soit pas multiplatforme est un défaut (il est tout à fait possible d'écrire du code portable cependant).

Certes mais c'est bien plus complexe car le C++ a beaucoup d'élément de base qui n'aident pas a aller dans ce sens, particulièrement les nombreux cas non déterminé de la spec, les type de taille variable, l'endianess, ... C'est un peu le reproche que je fait au C++ : c'est que les bons mécanismes sont généralement bien moins mis en valeur que les mauvais (généralement a cause de l'héritage du C).

Même une JVM ?

Théoriquement rien ne l’empêche, maintenant j'ai du mal a en voir l’intérêt.

[Invité]

Salut,
j'utilise ce langage depuis 5 ans déjà, non pas pour sa simplicité d'utilisation mais pour la résolution de problèmes plus complexe et de grosses applications multimédia à l'aide de la méta-programmation entre autre, ainsi que pour sa rapidité à l'exécution.
Je l'utilise également pour transférer des objets complexe en réseau.

Mais le nouveau standart du c++ n'est pas encore suffisant dans mon cas (même si il m'a rendu la tâche plus facile par moment, les choses peuvent vite devenir plus contraignante par la suite) :

Beaucoup de problèmes liés à ces nouvelles fonctionnalités :

-Les std::tuples_element et std::tuple_size ont besoin de la définition complètes des classes en compilation. (A cause de l'héritage fait dans ces différentes classes sûrement, je pense qu'il existe des implémentation similaire sans héritage mais je ne les connais pas et je ne sais pas si cela pourrait vraiment résoudre mes problèmes surtout si j'ai besoin d'appliquer un cast et un typeid.)
-Les macros ne suffisent pas toujours a résoudre des problèmes complexe, impossibilité de remplacer du texte dans un fichier ou bien d'en supprimer. (ça ne fait que du copier coller)
-Impossibilité de compiler une librairie sans passer le préprocesseur. (Il en parle ici mais malheureusement le lien de la lib est mort! : https://www.ideals.illinois.edu/bits...-2008-3009.pdf)
-Impossiblité de lire une constexpr dans un fichier et la passer en paramètre template. (Je ne sais pas si se sera possible avec le c++14.)
-Impossibilité d'inclure des fichiers en passant leurs noms à une macro variadique. (De plus il faut absolument connaître le nom des fichiers à inclure pour les passer à la macro lors de la compilation de la librairie.)

Bref je n'ai pas tout ses problèmes avec les autres langage comme par exemple le java, ou, lorsque je défini une classe, je peux utiliser un cast et tout ce que je veux même dans une classe template. (Par contre je ne pense pas que les templates variadique ça existe en java)
A vrai dire je crois que ce langage n'en a même pas besoin vu son système de réflexion et de serialization intégré, mais, le java perd en rapidité d'exécution face au c++ qui peut faire cela en compilation avec les template variadiques même si cela reste difficile et qu'il faut souvent passer par une librairie tierce.

Donc à partir du moment ou les librairies ainsi que les nouvelles fonctionnalités du c++ suiveront, le c++ restera un langage très utilisé.

[Astraya]

Le C++ n'a pas de garbage collector.

Je mettrais ça comme un avantage moi dans des situations métiers exigeantes. Pour faire de l'applicatif le garbage est un atout par contre j’avoue. Mais dans certains cas c'est plus une plaie qu'autre chose.

Le C++ doit recompiler pour être exécuter sur d'autre plateforme.

C'est un mal pour un bien. Plus de développement, plus d’investissement, plus de travail pour nous :p. Non sérieusement, c'est sur que ça demande de l'adaptation coté code et coté compilateur mais le code roule directement sur le processeur et n'est pas interprété, donc il sera toujours plus performant.

Le C++ est complexe à apprendre et 10 ans après il y a toujours matière à apprendre sur C++ et à s'étonner. Mais l'avantage de C++ c'est que avec un code, on peut faire ce que font les autres langages, avec plus de travaille certes... Le C++ est performant et surtout je pense que c'est une langage mature qui à prouvé son efficacité dans beaucoup de situation.


Sinon C++ mieux c'est tout.

[Astraya]

Car aujourd'hui la performance ce sont les carte graphique avec les shaders qui explose n'importe quel programme C++ au niveau performance.

Mais ou as tu choppé une idée pareil? les shaders sont basées sur quel langage selon toi? la seule différence de performance est du au faite que le programme est parallélisable à mort sur la CG, c'est juste une question matériel et pas software, met du C++ sur ta carte graphique et tu auras un résultat presque similaire. Essaye de comparer à du Java sur ta CG... ( je sais même pas si c'est possible)

Je pense que java est Le Langage de programmation qui permettra de tous faire dans ses futures versions.

Tout comme .NET, Haxe, Python...

[Saverok]

Je pense que java est Le Langage de programmation qui permettra de tous faire dans ses futures versions.

As-tu au moins lu l'article ??
L'auteur dit très clairement que le C++ n'est pas adaptés aux applications "modernes"
Java (ou autre langage de haut niveau) n'a pas les mêmes domaines d'applications que le C++
A chaque domaine, ses outils

Il y a eu plusieurs projets de faire des systèmes embarqués avec Java
Ca a été des échecs car Java est trop haut niveau justement et qu'il a fallu tailler dans le vifs pour l'alléger lui faisant perdre tous ses avantages par l’allègement de son jeu d'instruction. Et le tout, avec des perf moindre que le C++
La simple existence de la JVM provoque une consommation mémoire (et donc de batterie) incompatible avec les systèmes embarqués.

Je suis développeur Java depuis 10 ans et je kiffe ce langage mais ça n'empêche pas d'être conscient de ses faiblesses et de ses capacités

[Mouke]

Le C++ est performant et surtout je pense que c'est une langage mature qui à prouvé son efficacité dans beaucoup de situation.

Je pense que tout est résumé.

Je serais surpris de savoir lesquels. Pour moi, des langages comme le C, D, Ada, ... sont presque toujours des alternatives tout a fait valables au C++.

Déjà j'ai du mal avec cette comparaison... Surement mon inexpérience. Je ne parle pas pour le D, je ne connais pas du tout ce langage. En ce qui concerne le C, ce n'est pas un langage Objet. Quant à Ada, il possède effectivement un aspect objet mais il n'était pas conçu pour à la base. C++ c'est justement l'enfant né du langage C et de la POO. En ce sens, je ne considère pas ça comme une alternative. J'envisage plutôt les différents paradigmes comme des solutions différentes en fonction des besoins.
Sinon, un domaine ou le C++ règne en maitre : Le jeu vidéo. Je ne connais aujourd'hui pas beaucoup de jeux qui ne sont pas en C++ (ce sont soit des vieux jeux, datant de l'ère DOS, soit quelques jeux indé). Et je me souviens des débuts de Minecraft... On a senti l'absence du C++....

Sinon, Uther, BASIC pour débuter ? Sérieusement ?

Je suppose qu'il parlait du Visual Basic.

[Uther]

Je suppose qu'il parlait du Visual Basic.

Je parlais du langage Basic en général. Le Basic a avant tout été créé pour les débutant comme son nom l'indique.

Évidement je ne conseillerais pas un Basic antédiluvien avec numéros de lignes et goto partout. Mais à partir de QBasic, il y a déjà tout ce qui faut dans le langage pour permettre à un débutant d'pprendre les rudiments du codage.
Le Basic me semble un bon choix pour mettre en pratique les algorithmes, sans avoir à se poser dans un premier temps de question sur les détails techniques (pointeur notamment). Le typage n'est pas contraignant, sans être un foutoir comme pour JavaScript qui pour le coup peux donner de vraies mauvaises habitudes a un débutant.

[Luc Hermitte]

Moi j'aime pas C++ et préfère java pour les raison suivantes :
a- la syntaxe de java est plus simple.
b- Le C++ n'a pas de garbage collector.
c- Le C++ n'a pas d'API de d'introspection comme java.reflect.
d- Le C++ doit recompiler pour être exécuter sur d'autre plateforme.

e- Je pense que java est Le Langage de programmation qui permettra de tous faire dans ses futures versions.

a- Hum ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
// Java
TypeDeTroisKilometreDeLong var = new TypeDeTroisKilometreDeLong(args);
 
// C++
TypeDeTroisKilometreDeLong var{ args };
auto var = TypeDeTroisKilometreDeLong {args }; 
auto var = make_unique<TypeDeTroisKilometreDeLong>(args);

Perso j'aime bien quand on peut rester DRY (quitte à savoir plusieurs syntaxes)

Je pourrai aussi critiquer l'absence de surcharge d'opérateurs qui rend les opérations mathématiques au combien plus agréables à écrire en C++.
Je pourrai aussi critiquer l'absence d'héritage qui ne permette pas d'empêcher la substituabilité syntaxique (ou comment dériver une liste triée d'une liste sans violer le LSP).

Alors certes il y a des cas où le Java permet peut-être d'écrire des choses plus simplement, mais il y en a beaucoup d'autres où le C++ permet d'écrire des codes utilisateurs bien plus simplement.

b- Pas en standard, mais il existe plusieurs bibliothèques/frameworks qui ajoutent des GC. Perso, le RAII me suffit tout le temps. Et si ce sigle t'es inconnu, c'est probablement que tu connais pas assez le C++ pour le critiquer de façon éclairée. Si tu sais ce qu'est le RAII, alors tu sais à quel point on n'a pas besoin de GC pour gérer correctement *toutes* les ressources en C++ (et pas que la mémoire)

c- On en a autant besoin que ce tu as besoin de l'héritage multiple.

d- Oui, c'est vrai. D'ailleurs la JVM est compilée pour chaque plateforme ...

e- Sauf des OS industrialisés (Java coute trop cher pour vraiment partir dans cette direction), et sauf pour la JVM (car à un moment, il faudra bien une couche basse pour implémenter les GC qui fournissent de la mémoire ; et je doute que les implémentations de cela aillent s’embêter à le faire en assembleur)

f- Je sais, don't feed the troll, mais que voulez-vous, on est trolldi après tout.

[Luc Hermitte]

Je parlais du langage Basic en général. Le Basic a avant tout été créé pour les débutant comme son nom l'indique.

Évidement je ne conseillerais pas un Basic antédiluvien avec numéros de lignes et goto partout. Mais à partir de QBasic, il y a déjà tout ce qui faut dans le langage pour permettre à un débutant d'pprendre les rudiments du codage.
Le Basic me semble un bon choix pour mettre en pratique les algorithmes, sans avoir à se poser dans un premier temps de question sur les détails techniques (pointeur notamment). Le typage n'est pas contraignant, sans être un foutoir comme pour JavaScript qui pour le coup peux donner de vraies mauvaises habitudes a un débutant.

On a bien mieux depuis l'ère des BASIC (avec laquelle j'ai débuté) : Pascal, Ada, voire Python si tu ne veux pas imposer de phase de compilation qui vérifie les erreurs de typage. Et même un sous-ensemble du C++ peut être employé, cf. Je me lance de Francis Glassborrow où le débutant ne voit ni pointeur, ni classe à faire soit même, ni template à écrire soit même, ... Juste un C++ procédural et la SL.

[DonQuiche]

Je pense en effet que si la syntaxe était plus user-friendly, beaucoup plus de gens s'y intéresserait d'avantage.

Bof, pour moi ce n'est pas la syntaxe le problème, c'est son $#@$%*! de modèle de compilation à base d'inclusions et de substitutions de texte, et de headers. C'est lent, ça fait deux fois plus de fichiers, c'est fastidieux à gérer et ça produit des messages d'erreurs incompréhensibles en cascade quand le préprocesseur a rencontré sur une erreur. Et dans cinquante ans vous aurez encore des pelletées de biblios qui n'utiliseront pas de namespaces et colleront des dizaines de milliers d'identifiants aux noms cryptiques dans le global.

Chaque fois que je dois revenir au C++ c'est ça qui me me fait suer, cette sensation d'un retour en arrière de plusieurs décennies à cause de ce modèle de compilation. Mort aux en-têtes, mort aux inclusions, mort aux modèles de métaprogrammation conçus sans prendre en compte la difficulté du déboguage du processus de compilation. Je comprends tout à fait pourquoi ça a été fait ainsi à l'époque. Mais en 2014 ça fait mal. Ajoutez à ça d'autres vieilleries comme les digraphes (!) ou la gestion des chaînes de caractères.



Accessoirement, si on pouvait avoir une gestion automatisée de la mémoire et n'avoir à utiliser la gestion manuelle que lorsqu'on le désire, ce serait sympa. Mais a priori ça pose pas mal de problèmes, il faudrait que je regarde comment le D a abordé la chose (si je ne m'abuse il supporte les deux formules).

[Luc Hermitte]

1- Bof, pour moi ce n'est pas la syntaxe le problème, c'est son $#@$%*! de modèle de compilation à base d'inclusions et de substitutions de texte, et de headers. C'est lent, ça fait deux fois plus de fichiers, c'est fastidieux à gérer et ça produit des messages d'erreurs incompréhensibles en cascade quand le préprocesseur a rencontré sur une erreur. Et dans cinquante ans vous aurez encore des pelletées de biblios qui n'utiliseront pas de namespaces et colleront des dizaines de milliers d'identifiants aux noms cryptiques dans le global.

Chaque fois que je dois revenir au C++ c'est ça qui me me fait suer, cette sensation d'un retour en arrière de plusieurs décennies à cause de ce modèle de compilation. Mort aux en-têtes, mort aux inclusions, mort aux modèles de métaprogrammation conçus sans prendre en compte la difficulté du déboguage du processus de compilation. Je comprends tout à fait pourquoi ça a été fait ainsi à l'époque. Mais en 2014 ça fait mal.
2- Ajoutez à ça d'autres vieilleries comme les digraphes (!) ou la gestion des chaînes de caractères.

3- Accessoirement, si on pouvait avoir une gestion automatisée de la mémoire et n'avoir à utiliser la gestion manuelle que lorsqu'on le désire, ce serait sympa.

1- Il y a du travail en cours sur les modules. Il existe une version de clang qui implémente une tentative de modules pour avoir une preuve de fonctionnalité. Bref, des gens travaillent dessus pour le C++17. Il faudra encore attendre avant que tous les projets n'utilisent que ça et que les includes soient définitivement abandonnés.

2- Les digraphes viennent d'être dépréciés si je ne m'abuse.
Pour les chaines de caractères, ben il y a std::string. Pour l'UTF-8, c'est un chouilla plus compliqué. Il faut passer par des frameworks comme Qt ou boost.locale.

3- Si tu gères ta mémoire à la main, ton programme seras vite en inmaintenable en C++ -- un "grep -R delete * | wc -l" qui renvoie quelque chose dans une base de code C++ est un signe qu'il y a des choses à corriger. Une fois de plus, renseignez-vous sur le RAII. Depuis plus de 98 le principe est connu, depuis le début des années 2000 on a plein de shared_ptr<> dans plein de framework, et depuis 2011 il y a un type standard universel (pas forcément le meilleur pour tous les cas de figures, mais qui marche dans pratiquement tous les cas de figure).

Bref, NON on ne gère pas la mémoire à la main dans un programme C++. Pas si on le veut robuste et maintenable. Et non, cela n'impacte pas les perfs.

[ternel]

Mais arrêtez avec cette idée de la gestion manuelle.

unique_ptr, ça fait le café.
Tu sais juste que tu alloues, exactement comme avec un new MachinBidule() de java
Et le reste, c'est géré tout seul.

La règle étant "au déscopage du unique_ptr", plutot que "quand le garbage collector tournera et que le compteur de référence sera tombé à 0".
Dans les deux cas, le développeur n'écrit aucun code de largage.

Par contre, je suis d'accord que parfois, les en-têtes se mettent en travers du chemin.
Surtout quand des bibliothèques sont mal codées. Mais ça, on en trouve aussi dans les autres langages, avec des défauts similaires.

J'ai galéré avec du java pendant des mois, parce que j'étais obligé d'utiliser une lib de 300 classes dans un seul package, avec énormément d'erreurs entre les visibilités protected et package.
Chose que le C++ ne peut pas connaitre.

[DonQuiche]

1- Il y a du travail en cours sur les modules. Il existe une version de clang qui implémente une tentative de modules pour avoir une preuve de fonctionnalité. Bref, des gens travaillent dessus pour le C++17.

J'ignorais cela et c'est une excellente nouvelle, je te remercie. Le jour où ça sortira j'aurais peut-être envie de refaire du c++ (aujourd'hui je vois ça comme la croix et la bannière à chaque fois que je dois m'y remettre).

Une fois de plus, renseignez-vous sur le RAII.

Je sais parfaitement ce qu'il en est et ça reste de la gestion manuelle selon moi, bien qu'allégée : tu dois polluer ton code par des annotations mémoire systématiques, tu continues à te retrouver avec des fuites mémoire difficiles à comprendre, et il n'est pas rare du tout de devoir faire des changements profonds, notamment quand le dominateur d'un objet change (par exemple parce que tu as soudain besoin de persister ton objet plus longtemps que prévu, au-delà de la durée de vie de son précédent dominateur).

Et non, cela n'impacte pas les perfs.

Une incrémentation atomique (pour un shared_ptr) est loin d'être gratuite. Et ça ne va pas aller en s’améliorant avec la multiplication du degré de parallélisme du matériel. Mais c'est un point de détail dans la mesure où la solution bas niveau reste disponible.

unique_ptr, ça fait le café.

Dans les quelques cas où ça répond à ton besoin, oui.

[KsassPeuk]

Une incrémentation atomique (pour un shared_ptr) est loin d'être gratuite. Et ça ne va pas aller en s’améliorant avec la multiplication du degré de parallélisme du matériel. Mais c'est un point de détail dans la mesure où la solution bas niveau reste disponible.

A priori, le cas où l'on a plusieurs responsables (la clé de shared étant la responsabilité et pas l'accès) est rare et donc ne doit pas avoir d'impact violent sur les performances.