Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Pourquoi le langage C++ demeure incontournable 35 ans après sa sortie ?
Son créateur Bjarne Stroustrup revient sur les atouts du langage

Le , par Arsene Newman

114PARTAGES

13  0 
Créé il y a 35 ans de cela, le langage C++ demeure toujours un langage incontournable au sein de la communauté des développeurs et cela pour plusieurs raisons selon son créateur Bjarne Stroustrup.

Tout d’abord, Stroustrup tient à positionner son langage au sein de la panoplie de langages existants aujourd’hui, ainsi il explique que le C++ n’est peut-être pas le langage le plus adapté pour créer les applications modernes, mais « aucun langage ne peut exécuter des codes complexes aussi vite que le C++. De ce fait, si l’on prête attention à l’embarqué, au domaine du traitement d’image, aux télécommunications ou encore aux applications financières, le C++ règne en maître ».

L’informaticien danois revient aussi sur les langages qui connaissent une forte popularité en ce moment, à l’instar du langage Go de Google. Il note que ce dernier offre des solutions très élégantes dans certains cas, mais pour lui « Les langages qui se focalisent sur l’élégance des solutions perdent en contrepartie en terme de performance et de généralité, toutefois cela n’empêche pas de prêter attention à ces langages ».

Il rappelle entre autres que son langage est bien loin de la facilité d’utilisation des langages de scripts utilisés actuellement, cela est dû à une raison bien simple : « Le C++ est conçu pour les applications lourdes, il ne se focalise pas sur la facilité d’utilisation, par contre il a toujours été utilisé conjointement avec un langage de script », comme à l’époque de son développement où Stroustrup recourait à des scripts Unix Shell.

De ce fait, le « 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 ».

Enfin, pour le créateur du C++, son langage doit affronter aujourd’hui deux challenges majeurs : « soutenir les développeurs qui sont en charge des tâches les plus exigeantes en matière de performance, de passage à l’échelle et de fiabilité, mais aussi permettre aux développeurs d’être plus productifs en écrivant des codes plus faciles à maintenir ». Tout cela se traduit par les publications de nouvelles versions du langage, comme le C++ 11 et le C++ 14 qui doivent répondre à ces challenges en supportant une plus grande diversité matérielle et en introduisant de nouvelles fonctionnalités.

Source : Interview de Bjarne Stroustrup

Et vous ?
Qu’en pensez-vous ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Luc Hermitte
Expert éminent sénior https://www.developpez.com
Le 29/08/2014 à 11:54
Citation Envoyé par super_navide Voir le message
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
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.
7  0 
Avatar de Iradrille
Expert confirmé https://www.developpez.com
Le 29/08/2014 à 1:17
Citation Envoyé par super_navide Voir le message
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.

Citation Envoyé par super_navide Voir le message
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.

Citation Envoyé par super_navide Voir le message
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).

Citation Envoyé par super_navide Voir le message
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.

Citation Envoyé par super_navide Voir le message
Je pense que java est Le Langage de programmation qui permettra de tous faire dans ses futures versions.
Même une JVM ?
6  0 
Avatar de foetus
Expert éminent https://www.developpez.com
Le 28/08/2014 à 22:27
Citation Envoyé par super_navide Voir le message
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"

Citation Envoyé par super_navide Voir le message
Le C++ n'a pas de garbage collector.
Mais tu peux coder ton propre ramasse-miette. Eugen Systems le fait pour leurs jeux

Citation Envoyé par super_navide Voir le message
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

Citation Envoyé par super_navide Voir le message
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

Citation Envoyé par super_navide Voir le message
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

Citation Envoyé par super_navide Voir le message
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
7  2 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 29/08/2014 à 12:16
Citation Envoyé par Shuty Voir le message
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).
6  1 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 01/09/2014 à 16:30
Citation Envoyé par Matthieu Vergne Voir le message
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"
5  0 
Avatar de Gugelhupf
Modérateur https://www.developpez.com
Le 28/08/2014 à 14:34
Citation Envoyé par Shuty Voir le message
Je pense en effet que si la syntaxe était plus user-friendly, beaucoup plus de gens s'y intéresserait d'avantage.
Le C++ est devenu plus user-friendly avec C++11 et C++14, mais cela n'enlève rien à sa complexité qui prime sur le reste.

EDIT:
@Mouke
J'ignore si les dernières normes ont changé ça, en tout cas C++ (impose ?) permet la gestion mémoire avec les pointeurs et les malloc
malloc c'est du C, on n'est normalement pas censé utiliser cette fonction pour allouer de la mémoire en C++, il y a new, make_unique & les smart pointers.
5  1 
Avatar de Astraya
Membre expérimenté https://www.developpez.com
Le 29/08/2014 à 10:02
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...
4  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 29/08/2014 à 10:50
Citation Envoyé par super_navide Voir le message
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
4  0 
Avatar de ternel
Expert éminent sénior https://www.developpez.com
Le 29/08/2014 à 12:38
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.
4  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 29/08/2014 à 14:21
Salut,
Citation Envoyé par DonQuiche Voir le message
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).
je suis d'accord que c'est caché à l'utilisateur, mais, à ton sens, que fait l'instruction import de java?

Cela se fait au niveau de la JVM, mais, il n'y a rien à faire, cette instruction ne fait pas grand chose d'autre que ce que fait la directive préprocesseur #include au final, même si je t'accorde que c'est enrobé de manière à ce que l'utilisateur d'une classe n'ait pas **trop** à s'en inquiéter

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).
Pas si tu utilise correctement le RAII et que tu veilles à utiliser les classes RAIIsantes pour tes pointeurs

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.
Et, à ton avis, que fait le garbage collector de java, à part compter des références

La grosse différence entre java et C++ est que, au moins, tu as le choix de payer le cout de ce comptage de référence ou non, selon tes besoins, alors qu'il t'est imposé en java

Dans les quelques cas où ça répond à ton besoin, oui.
Si ce n'est que, si ta conception est bonne, tu devrais beaucoup plus souvent utiliser des unique_ptr que des shared_ptr.

A mon sens, il est beaucoup plus sain de se dire que, quoi qu'il arrive, il n'y a jamais qu'un et un seul objet qui, à un instant T, peut décider de détruire une ressource -- quitte à transférer de temps en temps cette responsabilité -- plutôt que de se dire que cette décision doit être collégiale.

Il y a, bien sur, des cas dans lesquels tu ne peux éviter le recours au shared_ptr, mais, à titre personnel, je ressent toujours ces situations comme un échec conceptuel, car je préfère de loin utiliser les unique_ptr, et que, je préfère encore purement et simplement éviter le recours aux pointeurs à chaque fois que faire se peut
7  3