Discussion :

[Stéphane le calme]

Le projet GNU annonce l'intégration du langage de programmation D dans GCC,
qui vient s'ajouter au C, C++, Objective-C, Java, Ada et Fortran

GNU Compiler Collection (GCC), l’ensemble de compilateurs créés par le projet GNU. GCC, est utilisé pour le développement de la plupart des logiciels libres. Le noyau Linux dépend notamment étroitement des fonctionnalités de GCC.

GCC est un logiciel libre capable de compiler divers langages de programmation, parmi lesquels le C, C++, Objective-C, Java, Ada et Fortran. À cette liste, vient s’ajouter désormais le langage de programmation D, comme l’a annoncé le projet dans une liste de diffusion : « Je suis heureux d'annoncer que le Comité directeur de la CCG a accepté l’inclusion dans GCC du langage front-end ainsi que du runtime D et a nommé Iain Buclaw comme responsable. Les correctifs nécessitent toujours l'approbation d'un évaluateur global », a annoncé David Edelsohn, Directeur de la technologie GCC chez IBM.

Le D est un langage de programmation impératif orienté objet et multiparadigme conçu pour la programmation système.

Il s’inspire de nombreux langages, dont entre autres C++, Java (avec lequel il partage la notion de « ramasse-miettes » et d’héritage simple), Eiffel (pour le paradigme de programmation par contrat).

Le langage D peut être considéré comme un langage de haut niveau par le fait de la simplification du code par rapport au C++, des frameworks Phobos et Tango qui permettent un niveau d'abstraction important, et surtout parce que le langage intègre nativement un ramasse-miettes. Le ramasse-miettes, comme en Java, permet de ne pas se préoccuper de la gestion de la mémoire et donc de simplifier les tâches d'écriture de code.

Cependant, le langage D est aussi considéré comme un langage de bas niveau, car il autorise :

• l'intégration de code assembleur, ce qui permettra de faire des optimisations importantes par rapport à l'architecture matérielle, mais rendra le code plus difficilement portable ;
• la désactivation partielle ou totale du ramasse-miettes, ce qui autorise une gestion plus précise de la mémoire.

Parmi les autres particularités de D, nous pouvons citer :

• la gestion de test unitaire en natif ;
• les modules ;
• les fonctions anonymes ;
• les structures de tableau ;
• la surcharge d'opérateurs ;
• la gestion des exceptions ;
• la documentation style javadoc ;
• les templates ;
• l'interfaçage avec des bibliothèques écrites en C.

Le compilateur officiel, DMD, est développé parallèlement à la spécification du langage. Il cible le langage machine. Une partie de son code (le frontend) est ouvert, ce qui permet de corriger rapidement les problèmes rencontrés, ou encore de réaliser son propre compilateur en utilisant une autre base (backend). Il existe actuellement pour les plates-formes Linux, Mac OS X et Windows.

Du côté de GNU, le compilateur GDC, mêlant le frontend de DMD et le backend de gcc avait été annoncé comme étant en développement.

Source : annonce de l'inclusion de D dans GCC

Voir aussi :

Débuter avec le langage D

Et vous ?

Avez-vous déjà utilisé le langage D ? Qu'en pensez-vous ?

[ddoumeche]

Voila qui va booster la popularité de D, langage qui a des intérêts absolument indéniables et est sans doute le futur remplaçant du c++

Mais rappelons quand même que D compile avec LLVM qui offre des performances d'exécution identiques à GCC pour un programme en C.

[captaindidou]

On ne peut plus d'accord.

[zobal]

langage qui a des intérêts absolument indéniables

Lesquels ? Parce que par rapport au C++11, je ne vois pas grand chose d'absolument indéniable dans l'article.

et est sans doute le futur remplaçant du c++

Et cela arrivera quand ? Parce que le D a quand même 18 ans...

[kopbuc]

Lesquels ? Parce que par rapport au C++11, je ne vois pas grand chose d'absolument indéniable dans l'article.

Syntaxe simplifiée par rapport aux C++ avec des perf's comparables + Garbage collector activable/désactivable. C'est déjà pas mal.

[ddoumeche]

Et cela arrivera quand ? Parce que le D a quand même 18 ans...

Bien malin qui peut le savoir. C++ a quand même 33 ans et est en perte de vitesse depuis plus de 10 ans.

[zobal]

Syntaxe simplifiée par rapport aux C++ avec des perf's comparables

Le C++11 simplifie généralement beaucoup la syntaxe. Et ce n'est peut-être pas la caractéristique primordiale d'un langage...

Garbage collector activable/désactivable.

En quoi, le garbage collector est un avantage ? Le RAII, la move-semantic et les pointeurs intelligents sont également des outils intéressants pour gérer la mémoire. Pour certains domaines, le garbage collector est même un inconvénient majeur (d'ailleurs Rust et Python n'en ont pas non plus).

Bien malin qui peut le savoir. C++ a quand même 33 ans et est en perte de vitesse depuis plus de 10 ans.

C'est ton ressenti, ton souhait ou le résultat d'une étude sérieuse ? Perso, mon ressenti c'est qu'il y a au contraire un regain d'intérêt depuis le C++11 et que le D ne risque pas de perdre de vitesse vu qu'il a toujours été à l'arrêt.

[ddoumeche]

Je vois qu'on a affaire à un passionné.

Petite erreur factuelle, Python comme la quasi totalité des langages à désinstanciation implicite (Lisp, VB6) a un ramasse-miette.

Pour répondre à ta question, combien de projets c++ lancés dans les entreprises ces dernières années ?

[Shepard]

Je rejoins Zobal ... C++ n'est pas du tout en perte de vitesse selon moi :O

Il suffit de regarder l'industrie du jeu video pour s'en convaincre ^^

Par contre D, je ne connais que depuis hier (enfin je connaissais de nom mais bon ...), uniquement parce que j'ai lu cet article ...

[Aiekick]

ca me fait toujours ticker quand je vois qu'on parle d'un langage qui intègre un GC.

il faut distinguer le langage du framework qui l'accompagne sinon on va retomber dans les histoires du nombre de ligne pour coder une fonctionnalité.

en C++ on peut tout faire, un GC c'est très simple a coder donc mauvais exemple de comparer ca au D. (d'ailleurs jamais entendu parler avant cette news)

des langages yen a plein, mais combien ont réellement percé ?

le java a explosé grâce a android. le java c'est une VM par noyau, le c++ c'est un compilateur par noyau, donc du code portable en c++ surtout en no lib c'est facile.

ce qui m'a toujours déplu avec le GC de java c'est de n'avoir aucun contrôle dessus. le bestiau ce déclenche quand ça lui chante, peu importe qu'on soit dans une boucle de calcul intensive ou non..

partout ou il y a besoin de faire un code le plus rapide que possible, on est en C ou en C++. donc bon, le D c'est comme le reste des langages. une fantaisie de plus.

travailler soit mème la mémoire est une chance pas un fléau. bien sur ça demande plus de compétence.

[ddoumeche]

Le GC de la JVM est paramétrable, et peut-être largement multithreadé. L'avantage est financier, beaucoup moins de temps passé à chercher les fuites mémoires.

Pour les portions de codes réclamant des performances maximales (c'est-à-dire 20% du code), rien n'empêche de faire des librairies externes, sans bytecode. Donc en C++ par exemple

[zobal]

Petite erreur factuelle, Python comme la quasi totalité des langages à désinstanciation implicite (Lisp, VB6) a un ramasse-miette.

Petite erreur factuelle, Python utilise un compteur de références, par défaut. Le garbage collector est disponible via un module spécifique ou avec des interpréteurs alternatifs.

https://docs.python.org/3/faq/design...-manage-memory

Pour répondre à ta question, combien de projets c++ lancés dans les entreprises ces dernières années ?

Je ne sais pas, j'avoue que je ne connais pas le fonctionnement interne de toutes les entreprises du monde. Par contre je connais les pages github de google, facebook et microsoft : 246 projets en C++, 1 projet en D. Mais peut-être qu'ils utilisent tous D pour leurs projets propriétaires...

[psykokarl]

Le projet GNU a tranché !
Le successeur du C/C++ sera le D et non le P (sorti relativement récemment)
M$ ne passera pas !

[Hassan.]

Je code en D depuis quelques années. Les avantages par rapport au C++ sont : une librairie standard beaucoup plus riche et facile à utiliser, une métaprogrammation très poussée, la CTFE qui veut dire que le compilateur exécute des fonctions au moment de la compilation dès qu'il le peut (comme sort par exemple : https://dlang.org/blog/2017/06/05/co...ime-sort-in-d/), l'UFCS qui permet d'écrire variable.fonction au lieu de fonction(variable) (comme les méthodes d'extension), les modules, le scope guard, les blocs unittest qui servent également de documentation pour le code, la sécurité contre les bugs de corruption de la mémoire (plus d'infos dans le talk de Walter Bright intitulé "Pointers gone wild" dont voici le lien), et les modules. Les modules écrits par les utilisateurs sont disponibles sur code.dlang.org et la gestion des dépendances se fait avec l'outil dub (comme composer en PHP).

En ce qui concerne la gestion de mémoire, le plus facile est de laisser le GC s'en occuper. En D le GC n'est pas imprévisible et donc son utilisation est idiomatique, il y a une série d'articles dans le blog officiel à ce propos : https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/

Ceci dit, il est également possible d'utiliser les pointeurs intelligents (Scoped, RefCounted, etc.) voire d'appeler directement GC.malloc et GC.free. La RAII peut être implémentée avec les blocs scope :

Code :

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

1
2
3
4
auto bloc = cast(ubyte *) GC.malloc(1024);
scope(exit) GC.free(bloc);
//on utilise bloc dans le reste du code

Le langage supporte également un mot-clé @nogc qui va forcer le compilateur à afficher des erreurs dans les lignes qui utilisent le GC dans votre code. Le problème à l'heure actuelle est que la bibliothèque standard (Phobos) et quelques fonctionnalités du langage (comme les exceptions) s'appuient sur le GC. C'est un souci qui empêche les devs de se passer pleinement du GC. Cependant, c'est une priorité de rendre Phobos indépendante du GC et on bosse actuellement dessus.

Plusieurs stratégies existent pour la gestion de mémoire. La plus commune est d'utiliser le GC dans le code en prenant soin de le désactiver (avec GC.enable, GC.disable, GC.collect) dans les zones où le profiling indique qu'il cause des problèmes de performances, mais il y a d'autres façons. Simon Arneaud en a parlé lors du DConf 2017 dans un talk intitulé "D as a better C" (en référence au flag -betterc du compilateur) en listant quelques projets existants et la façon par laquelle ils ont géré la mémoire, notamment les outils TSV d'eBay qui ont fait preuve de performances considérables malgré l'utilisation du GC.

On a récemment traduit le D tour en français, vous pouvez y jeter un coup d'oeil si ça vous intéresse : https://tour.dlang.org/tour/fr/welcome/welcome-to-d