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 !

C2 : un langage qui se présente comme une évolution de C
Plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements

Le , par Michael Guilloux

111PARTAGES

17  0 
Malgré ses 45 ans, le langage C a certainement encore de beaux jours devant lui, parce qu'il est déjà largement utilisé et qu'il y a des domaines qui restent encore sa chasse gardée, notamment l'embarqué et le développement d'applications où il est essentiel d'avoir du contrôle sur le matériel. N'empêche que certains essaient de se montrer comme un meilleur C. C'est le cas par exemple des langages D et Ritchie. Parmi ces langages, il y a également C2 qui est présenté par ses créateurs comme une évolution de C, plutôt qu'un remplaçant du langage de Dennis Ritchie.

« Le langage de programmation C existe depuis longtemps et est encore très utilisé de nos jours. Le noyau du langage est très solide, mais d'autres aspects montrent leurs limites avec le temps. C2 tente de moderniser ces parties, tout en gardant l'expérience de C. Il devrait être vu comme une évolution de C », est-il indiqué sur le site officiel du langage C2, en guise de philosophie du projet.

Cette philosophie a conduit l'équipe C2 aux objectifs de conception suivants :
  • une vitesse de développement plus grande ;
  • une vitesse d'exécution similaire, voire meilleure ;
  • de meilleurs temps de compilation ;
  • un système de build intégré ;
  • une syntaxe plus stricte (plus facile pour le tooling) ;
  • un excellent tooling (outil de formatage, outil graphique de refactorisation) ;
  • une intégration facile avec les bibliothèques C ;
  • un langage qui devrait être facile à apprendre pour les programmeurs en C ;
  • un langage qui devrait aider à éviter les erreurs communes.

Essayant de positionner leur langage par rapport aux langages de programmation actuels, l'équipe derrière C2 explique qu'il y a eu une tendance vers davantage d'abstractions de plus haut niveau, dans l'évolution des langages au fil du temps. « Java et C# reflètent particulièrement cette tendance. Pour les langages de niveau système, D et Rust se sont éloignés de cette tendance, pour fournir de meilleures performances et un meilleur contrôle », dit-elle. Avant d'ajouter que « pour un langage de niveau système, les fonctionnalités offertes par C++, D et Rust sont très appropriées. Cependant, ces langages ne semblent pas combler le vide pour les programmes de bas niveau/embarqués, car ils sont souvent encore programmés en C. C'est exactement ce vide que C2 tente de combler. »


C2 vise à être utilisé pour les problèmes où C est actuellement utilisé. Donc, les programmes de bas niveau comme les chargeurs d'amorçage (bootloaders), les noyaux, les pilotes et les outils de niveau système. Puisqu'il se veut une évolution de C, son équipe de développement a explicitement précisé que son objectif n'est pas d'introduire des fonctionnalités de niveau supérieur (comme l'orientation-objet, la récupération de mémoire, etc.) ou créer un langage complètement nouveau. Si C2 se présente comme une évolution de C, quels sont donc les changements par rapport à C ?

Ce qu'il faut savoir parmi les principales différences entre C et C2, c'est qu'il n'y a aucun fichier d'en-tête dans C2. C2 utilise en effet une approche dite moderne pour l'utilisation de symboles externes. Il n'y a qu'un seul type de fichiers, les fichiers source .c2. Pour remplacer #include, il existe une instruction d'importation. Tout le code source est également divisé en modules.

C2 vient en plus avec un système de build intégré. L'intégration du système de build dans le compilateur peut sembler restrictive, mais d'après les développeurs du langage, cela permet en réalité de nombreuses améliorations. L'une des fonctionnalités offertes par le système de build intégré est la compilation par cible (pas par fichier). Traditionnellement, les programmes C sont compilés par fichier, c'est-à-dire que chaque fichier est d'abord transformé en module LLVM. Mais en C2, le développeur peut choisir entre deux modes : le mode multimodule et le mode module unique. En mode multimodule (par défaut), tous les fichiers source d'un même module C2 sont transformés en un seul module LLVM. Le mode module unique quant à lui vise à permettre encore plus d'optimisation, car C2 convertit tous les fichiers source en un seul module LLVM, permettant une LTO (link-time optimization ou optimisation à l'édition des liens) complète.


Compilation (par fichier) avec C


Compilation avec C2 : mode multimodule (par défaut)


Compilation avec C2 : mode module unique

C2 fournit aussi les types primitifs prédéfinis suivants : bool ; i8, i16, i32, i64 ; u8, u16, u32, u64 ; f32, f64 ; et char (égal à i8). Les types int et float par défaut ont été supprimés avec les modificateurs de type short, long, signed ou unsigned. La macro NULL a aussi été remplacée par le mot-clé nil.

Une autre différence entre C et C2 est que C2 introduit une syntaxe de type uniforme. L'équipe derrière C2 estime en effet que les définitions de type en C sont parfois difficiles à lire. Aussi la syntaxe est un peu bizarre avec le typedef. Pour cela, C2 fournit une syntaxe uniforme pour définir de nouveaux types. Entre autres différences entre les deux langages, on peut encore noter des diagnostics plus stricts, les attributs, un tooling et des fonctionnalités spéciales dans C2. Les changements par rapport à C sont plus détaillés dans la documentation officielle de C2.

Cela dit, pourquoi donc choisir C2 par rapport C ? La réponse à cette question, d'après les créateurs de C2, se trouve dans les avantages que présente leur langage :
  • un développement plus rapide. Leurs tests auraient en effet montré une diminution d'environ 30 % du temps de développement avec C2 ;
  • un accès facile à des fonctionnalités telles que LTO (link-time optimization) ;
  • de meilleurs diagnostics (ce qui, encore une fois, accélère le développement) ; et
  • un contrôle plus facile de l'architecture avec c2reto.

Source : C2lang

Et vous ?

Que pensez-vous des objectifs du langage C2 ?
Croyez-vous qu'il fera une bonne alternative à C ? Pourquoi ?

Voir aussi :

Pourquoi les langages C et C++ auraient-ils encore de nombreuses années devant eux ? Donnez votre avis
Index TIOBE : C sacré langage de programmation de l'année 2017, Python enregistre encore la plus forte progression annuelle sur PYPL
Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D

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

Avatar de KsassPeuk
Membre confirmé https://www.developpez.com
Le 02/02/2018 à 13:51
Citation Envoyé par nougatine999 Voir le message
A la relecture des posts, on a l'air tous d'accord pour reconnaître que le C c'est la maman de tous les langages. Heu vive le C !
Ben heureusement que les rejetons ont pas hérité de tout son patrimoine génétique
7  0 
Avatar de Kannagi
Expert éminent https://www.developpez.com
Le 01/02/2018 à 17:54
Je doute que le langage C sera remplacé , encore une fois concurrencer le C veut dire vouloir concurrencer toutes les plateformes qu'ils visent (et ça doit être le seul qui vise effectivement tout les CPU existants ) , les lib et tout le code fourni jusqu’à présent chose très peu probable que C2 va être une alternative sérieuse.
Surtout que le C est utilisé sur des programmes très spécifiques , qui code une GUI en C ? presque personne x)
Qui va le faire donc en C2 ? Ben presque personne xD

Par contre un truc ou il risque pas de concurrencer le C , c'est dans un langage portable et performant (et je me demande vraiment si les concepteurs du langages ont réfléchi mûrement a leur décisions) :
"Les types int et float par défaut ont été supprimés"
Cool on va devoir remplacer manuellement tout nos i32 par i16 ou i8 suivant la plateforme

Le C est utilisé pour Linux , bon la c'est certain on va pas recodé les millions de lignes sur C2 (en plus il vise moins de plateforme que le compilo GCC ).
L'embarqué ? oui en utilise le C , mais aussi son remplaçant commence a être le C++.

De toute façon depuis l'arrivé de LLVM j'ai remarqué que de nombreux nouveau langages sont apparu :p
8  2 
Avatar de KsassPeuk
Membre confirmé https://www.developpez.com
Le 02/02/2018 à 13:35
Il y a pas mal de trucs qui me gênent avec ce "nouveau" langage. Le premier point, et à mon avis le plus important, c'est : "bordel où est la définition du langage ?". Le principal problème de C aujourd'hui reste quand même que sa norme, même si elle n'est pas si longue, est un bordel d'enfer avec des corner-cases partout, des ambiguïtés, des trucs franchement déplorable d'un point de vue définition (coucou strict aliasing rule) et la combinaison de ça c'est un joyeux foutoir. Et là, on a juste l'impression que c'est encore pire. La doc est pour ainsi dire inexistante.

Ensuite, on annonce sur le site "better diagnostics" dans les objectifs. Et là direct la question c'est : on a quoi pour les diagnostiques en question ? Parce que C commence à être bien équipé avec de l'analyse dynamique efficace (les debuggers C ont un overhead acceptable, on a les sanitizers), des analyseurs statiques qui marchent bien (clang-tidy et autres trucs du genre) et même des analyseurs statiques formels et sound (Frama-C, VCC, Verifast, ...). Et pour ces derniers, ça a notamment impliqué de définir formellement ce qu'est un programme C correct, ce qui a demandé un sacré boulot. Là l'idée c'est de recommencer pour ce langage qui ne semble franchement pas être mieux défini que C.

Concrètement sur les points de la capacité à analyser les programmes qu'on écrit Rust semble largement mieux parti (par exemple avec des choses comme Patina ou le projet RustBelt). Et on a quelque part de besoin de quelque chose de mieux conçu que C pour les tâches qu'on réalise avec (notamment dans le critique), parce que la norme est un vrai problème pour avoir des compilateurs et des programmes qui tiennent la route avec un très haut niveau de qualité. Il y a qu'à voir comment les développeurs de CompCert ou seL4 en ont chié alors que c'est des tueurs.
5  0 
Avatar de MrKuja
Nouveau membre du Club https://www.developpez.com
Le 01/02/2018 à 17:03
Citation Envoyé par transgohan

Je reste très sceptique...
Cela ne semble pas apporter grand chose, de plus quand je vois qu'ils annoncent 30% de gain de temps de codage alors que l'exemple hello world :
Code : Sélectionner tout
1
2
3
4
5
6
7
8
module hello_world;
 
import stdio as io;
 
func i32 main(i32 argc, char*[] argv) {
    io.printf("Hello World!\n");
    return 0;
}
Comporte plus de mot clé qu'un programme codé en C... On a envie de leur demander un compte rendu exhaustif de leurs tests...
Parce que personnellement je mettrai forcément plus de temps à écrire ce code que le même en C, c'est physique...
Pour voir son intérêt il ne faut pas se limiter à un simple hello world.
Si le C2 apporte plus de cohérence cognitive, quitte à ce que certains morceaux soit un poil plus verbeux sincèrement c'est mieux.

Le gain de la syntaxe et du système se verrait sur des cas concrets dépassant le hello world.

On verra dans le temps si ça prend. Ou non...
4  0 
Avatar de ternel
Expert éminent sénior https://www.developpez.com
Le 05/02/2018 à 7:46
Pour le gestionnaire de paquets officiel, c'est directement lié au fait que ces deux langages sont définis par une norme, et non une implémentation de référence.

De fait, il y a plusieurs fournisseurs officiels de compilateurs, et aucun ne peut prétendre être plus "officiel" que les autres.
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 12/02/2018 à 10:03
Je pense pas que le nombre de mot clé a taper ait la moindre incidence sur la vitesse de codage : on passe généralement bien plus de temps a lire et réfléchir au code qu'à le taper.
Avoir un code clair et bien structuré fait gagner bien plus de temps que les fractions de secondes utilisées a saisir des mots clé.
4  0 
Avatar de Matthieu76
Membre éclairé https://www.developpez.com
Le 01/02/2018 à 16:22
Bof, je sais pas trop quoi en penser ... Je trouve que c'est beaucoup pour pas apporter grand-chose.

Personnellement, je pense qu'il y a trop de language de programmation. Après ça sera quoi, le C++2 ???
3  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 01/02/2018 à 17:06
Citation Envoyé par Matthieu76 Voir le message
Après ça sera quoi, le C++2 ???
C++20

Le "problème" de C c'est qu'il évolue très doucement. Une spec en 99 , une en 2011 , je comprend que si on commence un projet en 2018 , travaillé avec un spec d'il y'a 7 ans peu être frustrant.
C++ de son coté à un rythme de màj de 3 ans (11,14,17,20,...) qui apporte à chaque fois des évolutions bienvenues
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 02/02/2018 à 14:40
Citation Envoyé par Kannagi Voir le message
La raison de l'utilisation du C le plus utilisé , c'est que c'est le langage le plus utilisé par les étudiants voila l'explication
Et s'il est tant appris par les étudiant c'est aussi parce qu’il est historiquement très utilisé dans l'industrie particulièrement pour tout ce qui touche au bas niveau et à l'UNIX.

Citation Envoyé par Kannagi Voir le message
Faire des calculs 32 bits sur du 8/16 bits te prendra forcément beaucoup plus de temps que de faire un calcul sur 8 bits
Dans l'exemple que tu cites, c'est en effet plus rapide. Mais ça ne sera pas forcément vrai dans tous les cas. Il y a par exemple sur certains processeurs des opérations plus rapides avec des opérandes de taille plus petites que le mot habituel.
Si tu veux vraiment te soucier d'optimiser au mieux ton programme il vaut beaucoup mieux être sur de la taille de chacun de tes types et adapter au cas par cas si l'optimisation du compilateur ne suffit pas.

Par contre les types de taille variable peuvent donner de gros problèmes de fiabilité lors du portage. Dans ton exemple où tu recompiles directement en 8/16 bit du code conçu pour du 32 bit qui utilise "int" , le risque est énorme. Tu peux te retrouver avec des erreurs dues à des débordements dans du code qui marchait pourtant très bien en 32 bit. Avant de se soucier d'avoir un code rapide, il faut se soucier d'avoir un code qui marche.
3  0 
Avatar de mister3957
Membre expérimenté https://www.developpez.com
Le 04/02/2018 à 20:21
Y'a un truc que je ne comprends pas, c'est que le C ou le C++ n'ont pas de gestionnaire de paquets.

En Java il y a Maven, .Net a NuGet, NodeJS a NPM, Python a PIP etc. et rien pour C/C++.

Pour moi si il doit y avoir une évolution dans l'écosystème C/C++ c'est pas "pouvoir programmer plus vite", mais un gestionnaire de paquets pour maîtriser les versions, les déploiement, les dépendances etc.

Il y a eu quelques projets pour ça, mais flop. Est-ce que c'est parce que ce n'est pas suivi / supporté ? Ou des contraintes particulières ?
3  0