Discussion :

[super_navide]

En général , les gens qui donne l'absence de garbage collector comme un point fort du langage C++ ne savent pas comment fonctionne un garbage collector.
Celui de java est l'un des plus évolué, il peut fonctionner en parallèle sans pratiquement geler la machine virtuelle.
Le garbage est un sécurité suplémentaire.

En plus ceux qui dise qu'on peut le faire en C++ il me font bien rire allez donc parcourir la pile d'execution , déplacer les objets entre une jeune génération et une vieille génération, enfin faire le travail complexe d'un GC dans le langage lui même , seul la technic du compteur de référence peut être facilement réalisable.


Il y une chose importante aussi , c pas parce qu' un langage comme COBOL ou C++ est beaucoup utilisé dans la finance ou autre qu'il est le langage le plus adapté pour ce domaine.
Bcp sur ce forum n'ont pas l’expérience professionnel pour savoir que dans le monde de l'entreprise on ne réécrit pas un programme qui fonctionne correctement dans un langage qui pourrait être plus adapté.
Si en entreprise un programme en C++ ou en COBOL fonctionne bien il ne sera jamais réécrit en java même si celui-ci serait plus adapté, ça coûte trop chère et c une question de bon sens.


J'ai toujours remarqué que les pros C++ était des intégristes de leur langage, C++ était le meilleur dans langage avant et au début de java c sur mais les temps change, comme on a bien cru que C# allé remplacé java.

Peut être un jour java trouvera un meilleur concurrent mais pas aujourd'hui..................

[Luc Hermitte]

J'ai toujours remarqué que les pros C++ était des intégristes de leur langage, C++ était le meilleur dans langage avant et au début de java c sur mais les temps change, comme on a bien cru que C# allé remplacé java.

Et finalement c'est python ...
(J'en profite on est encore Vendredi).

Le truc est que là, c'est parti d'un troll qui ne connaissait pas le C++. Après, pour les langages, chacun a ses préférences. Imagine que l'on débarde en disant le GC de Java est trop pourri : il ne gère pas les cycles, et en plus la SortedList standard dérive de List. C'était vrai. En Java 1. Dire que l'on gère la mémoire à la main en C++, c'est tout aussi ridicule depuis 15ans -- à la différence que même dans eux qui utilisent le C++, nombreux sont ceux à le faire (à la main), et presque aussi nombreux sont ceux qui croient que c'est bien, et qui préfèrent continuer ainsi plutôt que de remettre en question leurs bases C et d'apprendre à utiliser le C++.
Il ne faut pas être surpris quand certains s'en agacent et partent au quart de tour.

[JolyLoic]

En général , les gens qui donne l'absence de garbage collector comme un point fort du langage C++ ne savent pas comment fonctionne un garbage collector.
Celui de java est l'un des plus évolué, il peut fonctionner en parallèle sans pratiquement geler la machine virtuelle.
Le garbage est un sécurité suplémentaire.

Un des principaux problèmes d'un GC est que pour qu'il marche sans se voir, il faut disposer de plus de mémoire que nécessaire. J'avais vu une étude sur le GC Java où ils disaient qu'en gros (pas les bons chiffres, juste les ordres de grandeur), quand tu as 6 fois plus de mémoie que nécessaire, le GC ne se voit pas en terme de perfs (mais son gel de thread le rend quand même inutilisable pour du temps réel). Quand tu as 2 fois plus de mémoire, l'impact est visible mais faible, quelques %. Moins que ça, l'impact augmente en flèche.

Le fait de geler la VM semble assez important pour que par exemple Apple ait supprimé le GC d'objective C et refuse d'en mettre en swift.

En plus ceux qui dise qu'on peut le faire en C++ il me font bien rire allez donc parcourir la pile d'execution , déplacer les objets entre une jeune génération et une vieille génération, enfin faire le travail complexe d'un GC dans le langage lui même , seul la technic du compteur de référence peut être facilement réalisable.

Il existe pourtant des GC génériques en C++. Je ne dis pas que c'est trivial à mettre en place. Et généralement, ce sont des GC qui ne déplacent pas les objets en mémoire, et n'évitent donc pas forcément la fragmentation.

[super_navide]

Le point faible de C++ par rapport à java est le byte code qui représente une abstraction de l'assembleur.
Cette abstraction ne permet pour l'instant de ne pas avoir les même performance que le C++ mais les écarts diminue.
Il y a quelque année on disait qu'aucun jeux videos ne serait fait en java à cause du GC qui gèle la VM, Mincraft est en java .....!!!!!


La prochaine version de java qui inclura le type values écrasera C++ et probablement la VM sera réécrite en Java puis le byte code compiler pour la machine cible et la boucle sera bouclée le tous java............

la seul chose qui restera pour le C++ encore longtemps est l'écriture d'un OS et de ses drivers, mais pour combien de temps !!!!
on pourrais imaginer des instructions du byte code java pour gérer directement le materiel mais bon la je vois pas l'intéret..........

[Matthieu Vergne]

« C++ est pour la haute performance, la haute fiabilité, le faible encombrement, la faible consommation d’énergie et pour toutes ces bonnes choses, non pas pour les amateurs et les applications rapides, car cela ne relève pas de son domaine ».

Vu qu'on parle de haute performance, j'imagine que ces "applications rapides" font référence aux "applications codées rapidement". Cette phrase me fait quand même un effet très sarcastique. Style "le C++ permet de bonnes choses, mais non désolé il n'en permet pas de mauvaises, nyark nyark".

En le prenant autrement on peut en comprendre que le C++ n'est pas fait pour les débutants et le prototypage. Il est donc préférable de se former avec un autre langage pour apprendre plus en douceur et de faire des prototypes avec un autre langage qui permet de coder plus rapidement sans se soucier de tous les menus détails, qui peuvent être pris en compte plus tard. Perso, c'est un peu pour ça que je suis passé de C++ à Java : dès lors que tu veux tenter des trucs, ça devient une vraie gageure de le faire en C++. Il faut charger 300 bibliothèques pour faire le moindre truc de base et pour les débutants tu passe plus de temps à déboguer qu'à coder ton application. En tout cas, c'est la vision que j'en avais en 2009 qui m'a fait switcher à Java. Maintenant je sais que pas mal de choses ont changé et si je devais me remettre au C++ il me faudrait me reformer depuis la base. Mais apparemment, la perspective est toujours la même : privilégier la performance à la facilité d'utilisation. Du coup je doute qu'avec mon caractère très expérimental je m'y remette sérieusement.

[Luc Hermitte]

Le C++11 s'est voulu moins orienté vers les experts que le C++98 ne le fut.
C'est là que sont arrivés certains sucres syntaxiques, et autres petites améliorations.

Reste que cela ne corrige en rien qu'il faille savoir coder un minimum. Toutes les difficultés & subtilités du Génie Logiciel sont là de même que celles du paradigmes OO, ... Quand on prototype, ce n'est pas trop le genre de choses avec lesquelles ont s'encombre.

Côté écosystème, la lib standard est toujours aussi maigre. Il faut se tourner vers boost et/Qt pour compléter les manques principaux. Il faut se tourner vers d'autres sources pour Java également (Apache, eclipse RCP, middleware, ...), mais dans l'ensemble sa lib standard est plus fournie.

[ternel]

[...] le C++ n'est pas fait pour les débutants et le prototypage. [...] Perso, c'est un peu pour ça que je suis passé de C++ à Java : dès lors que tu veux tenter des trucs, ça devient une vraie gageure de le faire en C++. Il faut charger 300 bibliothèques pour faire le moindre truc de base et pour les débutants tu passe plus de temps à déboguer qu'à coder ton application. [...]

Je ne suis pas d'accord avec cela.

Je code régulièrement des prototypes en C++, sans lib externe, en général.
Par contre, je reconnais que d'avoir Swing sous la main donne à java l'avantage pour prototyper une interface graphique

C++ est un langage assez simple en lui même. Pour peu qu'on accepte d'apprendre comment ca marche en dessous.

Mais le problème est le même en java.
Il faut savoir le for( : ) fonctionne sur les iterables en invoquant iterator(),
que les objets sont passés par références (comment ca, des pointeurs cachés...)
que toutes les classes héritent indirectement ou non d'Object.
qu'il faut explicitement appeler new sur chaque objet... (pas de gestion de la mémoire?)
que les exceptions qui héritent de RuntimeException n'ont pas à être déclarée dans la "throws", et peuvent être attrapée régulièrement.
que les génériques n'acceptent pas int, et donc qu'il existe un mécanisme de boxing/unboxing presque magique.

Bref, que les fonctionnalités du langage sont intimement entrelacées avec la bibliothèque standard.

[koala01]

Vu qu'on parle de haute performance, j'imagine que ces "applications rapides" font référence aux "applications codées rapidement". Cette phrase me fait quand même un effet très sarcastique. Style "le C++ permet de bonnes choses, mais non désolé il n'en permet pas de mauvaises, nyark nyark".

En le prenant autrement on peut en comprendre que le C++ n'est pas fait pour les débutants et le prototypage.

Je suis justement occupé à la rédaction d'un ouvrage qui tend à démontre le contraire (pour ce qui est des débutants du moins).

Il est donc préférable de se former avec un autre langage pour apprendre plus en douceur et de faire des prototypes avec un autre langage qui permet de coder plus rapidement sans se soucier de tous les menus détails, qui peuvent être pris en compte plus tard.

Peut être, à un bémol près : il ne faut jamais en arriver à considérer les principes de base du (des) paradigne(s) utilisés comme étant de "menu détails".

Si tu penses, par exemple, aux pointeurs et à la gestion manuelle de la mémoire, tu as (en partie) raison : il ne sert à rien de s'inquiéter de ces détails lors de l'apprentissage. Mais C++ permet de s'en passer jusqu'à ce qu'on aborde les problèmes liés au point réellement neuf du paradigme oo : la substituabilité et son pendant que sont les comportements polymorphes.

Par contre, si tu considère les principes SOLID ou la loi de déméter comme de "menus détails", tu mérites sans doute de te faire pendre par les pieds au dessus d'un feux de joie

Il est tout à fait vrai que C++ part du principe que le développeur sait ce qu'il y a toujours une bonne raison à ce qu'il fait, privilégiant à chaque fois la fonctionnalité utile (à condition d'être correctement utilisée) à la sécurité d'une fonctionnalité non fournie.

D'autres langages ont une philosophie différente, mais c'est sans doute cette différence de philosophie qui permet le mieux de choisir le langage "qu'on préfère"

[jblecanard]

Salut

Le "succès" du langage ne tient pas qu'à ses caractéristiques techniques mais également à l'histoire humaine de celui-ci. Le succès de C++ aujourd'hui n'est pas lié qu'à ses particularités, il est lié aussi au fait qu'il est massivement utilisé dans l'industrie et que de coûteuses et volumineuses solutions logicielles sont faites avec. Dans ces conditions, changer de langage aurait un coût totalement exhorbitant pour nombre de domaines, que ce soit en réécriture de code, en coût de formation et de recrutement de développeurs, et autres auxquels je ne pense pas encore. Il vaut mieux faire évoluer l'existant (et d'ailleurs, Stroustrup dit lui même que la rétro-compatibilité est une feature en C++, je met pas le lien car il va mettre une miniature vidéo forcée et je veux pas) que partir sur un nouveau langage.

Sans que cela mette en doute ce qui est dit sur la partie technique, c'est un facteur, parmi d'autres, à prendre en compte. A supposer qu'un langage aussi bon et adressant les mêmes problématiques soit inventé, il ne pourrait avoir autant de ce succès à cause de ce facteur historique. Un facteur qui concerne aussi d'autres langages et qui fait que nous aurons encore du C et du Java pour de longues années.

[Médinoc]

je met pas le lien car il va mettre une miniature vidéo forcée et je veux pas

Regarde dans les options sous la TextBox quand tu postes, tu verras des cases à décocher pour éviter cela.

[moldavi]

Bonjour.

Il ne faut pas perdre de vue que les performances d'un programme ne sont pas pas intrinsèquement liées à un langage.

En effet le compilateur à son mot à dire. Un bon langage comme le C++, avec un compilateur médiocre, et tout le monde dira que le C++ n'est pas performant.

Les langages interprétés comme C#/Java ajoute des instructions au code (l'interprétation + GC et autre truc), ce qui fait que ces langages seront toujours moins performants que le C++. C'est juste de la logique : moins d'instruction, plus de performance. Cela est encore plus flagrant au niveau du GPU : une instruction en moins, et c'est 2 fps de gagné, surtout avec des millions de poly).

Les langages interprétés comme C#/Java ont l'avantage de la rapidité de développement et du portage. Mais pour les performances le C++ a encore de longues années devant lui.

Les langages interprétés sont encore perdants face aux langages impératifs, en terme de performance.

De toute façon, si un langage était "Performant", "Portable", "Rapide à développer", cet article n'aurait pas lieu d'être. Chaque langage a ses avantages et ses inconvénients. Au développeur d'utiliser ceux-ci à bon escient.

[Matthieu Vergne]

On est d'accord. Un paradigme, on le prend ou on le jette. On l'imagine pas à sa sauce pour se plaindre après que ça marche pas comme on veut. Je parle bien du fait que, une fois que tu as installé Java, tu as tout ce qu'il faut pour t'amuser avec des concepts haut niveau, jusqu'aux interfaces graphiques. Après, libre à toi de rajouter des libs et de refactorer ton code pour les utiliser, mais au moins tu peux démarrer tout de suite. En C/C++, la sélection et installation de libs est quasi-obligatoire, sinon on en reste à des exercices d'écolier et à réinventer la roue. Si aujourd'hui on a des grosses libs qui fournissent de nombreuses bases de manière homogène, avant c'était pas le cas, et c'était bien là le problème (et le gros avantage de Java à ce moment là). J'imagine qu'aujourd'hui, tu as une ou deux libs typiques que tu utilises dans tous tes projets et à partir de ça tu fais un peu ce que tu veux, comme en Java (avec la config initiale en plus pour les utiliser). Mais comme ça fait longtemps que j'ai pas codé en C++, je peux pas m'avancer plus.

[ChristianRoberge]

Le C++ est un mauvais langage car il y a plusieurs façons de faire la même chose (Des bonnes et de très mauvaises!). Après 25 ans de programmation avec ce langage, il y a toujours de nouvelles façons de faire. Les nouvelles normes C++11 et C++14 amènent encore plus de confusion dans un langage qui était déjà fort complexe. Toutefois, quand on réussis à maitriser la bête, c'est un langage que l'on ne peut se passer. Les performances ont un prix. Plusieurs aiment des solutions simples et rapides, mais on oublie souvent qu'outre les performances médiocres, l'extensibilité et la réutilisation haut niveau du code est aussi moindre en C++. Quand on travaille dans un même domaine, comme moi, l'avantage du C++ est alors incommensurable par rapport aux autres langages à long terme. Je n'ai pas vu de d'autres langages qui le surpasse.

[frantzgac]

Programmer signifie concevoir et manipuler des concepts abstraits.
Soit on maîtrise les concepts qu'on utilise, soit on confie à des outils le soin de manipuler les concepts et de nous fournir un résultat.
Dans le premier cas le temps d'apprentissage est long mais la maîtrise permet d'utiliser les outils en comprenant leur fonctionnement et éventuellement en anticipant leurs faiblesses.
Dans le second cas l'apprentissage sera toujours en retard sur l'océan d'outils.
Dans un monde qui privilégie la vitesse (appelée parfois productivité) il n'est pas surprenant que la seconde solution soit populaire. D'autant plus qu'elle est très démagogique.
Mais si C++ conserve ses adeptes c'est peut être pour la même raison que COBOL. Bien des applications mille fois modifiées ne sont pas documentées et fonctionnent à peu près. Cela coûterait fort cher de les repenser et pire encore de les réécrire.
Les bons choix résultent aussi parfois de mauvaises raisons...

[Invité]

Je pense que le langage va même être encore plus populaire à l'avenir car il permet non seulement de garder des anciennes solutions qui coûteraient trop cher en production pour être remaniée, mais maintenant avec le c++ moderne le langage permet de faire des choses de manière plus rapide avec beaucoup moins de complexité. (Gestion automatique de la mémoire avec std::unique_ptr, std::shared_ptr, etc..., système de callback simple avec std::function et la méta-programmation (avec les macros pour remplacer les systèmes de réflexion et garder ainsi la rapidité du langage à l'exécution), système de sérialisation de données simple avec la combinaison de tout ça)

c++14 me permet maintenant de faire des choses très complexe de manière simple et rapide, sans pour autant nié l'apprentissage grâce aux nombreuses librairies opensource utilisant encore du c++ 98 voir même du c.

Parfois ce n'est même pas nécessaire de passé par la couche orienté objet pour les petites libs et le c++ est compatible avec un language non orienté objet. (Le C)

Ce qui est aussi un grand atout que je n'ai pas retrouvé dans d'autres language.

[the Hound]

Je pense que le langage va même être encore plus populaire à l'avenir car il permet non seulement de garder des anciennes solutions qui coûteraient trop cher en production pour être remaniée, mais maintenant avec le c++ moderne le langage permet de faire des choses de manière plus rapide avec beaucoup moins de complexité. (Gestion automatique de la mémoire avec std::unique_ptr, std::shared_ptr, etc..., système de callback simple avec std::function et la méta-programmation (avec les macros pour remplacer les systèmes de réflexion et garder ainsi la rapidité du langage à l'exécution), système de sérialisation de données simple avec la combinaison de tout ça)

Mouais ... à mon avis on ne fait que troquer des connaissances contre d'autres, et si avant tu devais apprendre comment on se sert d'un T* et comment ça marche, à présent tu dois savoir comment on se sert d'un unique_ptr et dans quels cas l'utiliser. Tu vas te préoccuper plus de la sémantique que de la mémoire, certes, mais ça ne simplifiera pas forcément le langage. Un exemple : l'ajout des références sur rvalues, qui a complexifié les notions de lvalue et rvalue, et maintenant on a xvalue, rvalue, prvalue, lvalue et glvalue ...
Quant aux évolutions du langage, c'est comme ça pour n'importe quel langage "vivant" (utilisé par une communauté conséquente et non seulement par un barbu dans sa cave), et heureusement que le langage évolue.

c++14 me permet maintenant de faire des choses très complexe de manière simple et rapide, sans pour autant nié l'apprentissage grâce aux nombreuses librairies opensource utilisant encore du c++ 98 voir même du c.Parfois ce n'est même pas nécessaire de passé par la couche orienté objet pour les petites libs

En gros t'es en train de dire que :
- on peut lire des sources en C++,
- on n'est même pas obligé d'utiliser toutes ses fonctionnalités.

Mais c'est révolutionnaire ça dis-moi

et le c++ est compatible avec un language non orienté objet. (Le C)
Ce qui est aussi un grand atout que je n'ai pas retrouvé dans d'autres language.

Ça peut être vu comme un atout ou un inconvénient.
Le fait est que la compatibilité avec C a toujours été une priorité, et cela a en réalité entravé le développement du C++.
L'agencement des structures en mémoire, la déclaration en int par défaut, ... sont des reliques du C qui n'ont que complexifié le standard et parfois même empêché d'implémenter certaines fonctionnalités (le mot-clé auto a été créé il y a plus de trente ans par Stroustrup lui-même semblerait-il, mis de côté pour une rétrocompatibilité avec C).
Donc oui, c'est bien, et c'est pas bien à la fois.

PS: je ne critique pas C++, au contraire c'est de loin mon langage préféré. Mais j'étais obligé de réagir en lisant ce post.

[Matthieu Vergne]

Grosso modo, même avis que ci-dessus.

Parfois ce n'est même pas nécessaire de passé par la couche orienté objet pour les petites libs et le c++ est compatible avec un language non orienté objet. (Le C)

Ce qui est aussi un grand atout que je n'ai pas retrouvé dans d'autres language.

Sauf que le but de l'objet c'est de faire du haut niveau. Avoir un langage qui te permet de faire les deux est plus flexible, mais en contre partie quelqu'un qui a l'habitude de faire de l'orienté objet aura du mal à prendre en main un code bas niveau, et vice-versa. La richesse d'un langage ne prend sa valeur que quand on essaye de pousser sa maîtrise jusqu'au bout, ce qui est rarement le cas en production (on peut avoir quelques héros, mais on en a rarement une équipe entière). Sans ça, ce n'est qu'offrir plus de moyens de se perdre en faisant du code hétérogène et généralement sale.

[Invité]

Il est vrai que je fais du c++ depuis plus de 5 ans et pourtant ça m'arrive encore de faire du code salle.
J'ai commencé par le c++98, j'ai juste du réapprendre le c++14 avec les rvalue et lvalue références ainsi que std::unique_ptr et std::function pour faire du code plus propre, avec l'aide de certains membre de se site c'est passé tout seul.

Donc bon oui on peut facilement faire du code salle en c++, plus facilement que dans d'autres langages comme par exemple le java et c'est pour ça qu'il ne faut pas hésiter à demander de l'aide sur les forums et à montrer son code. (Car au niveau sémentique le c++ reste quand même le language le plus compliqué que je connaisse surtout depuis l'arrivée des rvalues, lvalue, etc...)
Mais une fois que tu sais t'en servir ça devient, un énorme avantage.

[yahiko]

Même si je ne l'utilise plus depuis belle lurette parce que ce n'est pas le langage de prédilection de mon domaine, j'en garde de très bons souvenirs.
Longue vie au C++ et que se termine l'arnaque de Java.

[Matthieu Vergne]

C'est pas parce que Java ne te correspond pas qu'il ne correspond à personne.