Discussion :

[Patrick Ruiz]

Une université canadienne propose C-for-All
Un projet open source d’extension du C ISO avec des fonctionnalités « modernes »

Qui pour assurer la succession du langage C ? La question revient constamment au sein des communautés de développeurs. Par le passé, des noms de candidats ont fait l’objet de fuites ; depuis 2009 on évoque Go, un langage de programmation développé par Google et inspiré de C et Pascal. Mozilla Research aussi œuvre dans le cadre de cette mouvance et, depuis 2006, propose Rust, un langage qui permet de faire la programmation sous plusieurs paradigmes. Cette liste s’allonge avec C-for-All, une initiative conjointe du géant chinois Huawei et de l’université de Waterloo au Canada.


Le langage C a encore de beaux jours devant lui. Référence faite à un sondage paru sur cette plateforme en janvier de cette année, quatre raisons permettent de soutenir cette affirmation. Primo, n’en déplaise à ses détracteurs, C est encore largement utilisé. Secundo, il sera toujours nécessaire d’être à même de faire « joujou » de façon aisée avec le hardware et pour des tâches de ce type, le langage C continue de faire partie des premiers choix. Tertio, le langage est reconnu pour l’efficacité de son code source. Enfin, le langage se prête bien aux tâches de développement d’applications multiplateformes, ce à quoi les férus font souvent référence en parlant de portabilité.

Le langage C dispose d’un atout supplémentaire dans sa manche : il continue d’évoluer. C++ est né en 1983 pour répondre à ce besoin et connait des mises à jour régulières : C++11, C++14 puis C++17, des révisions qui ont respectivement vu le jour en 2011, 2014 et 2017. Il faudra désormais compter avec C-for-All dont l’université de Waterloo a publié la liste des extensions qui en font un C ISO qui continuera de traverser les âges.

C-for-All propose la gestion des exceptions comme extension à l’ISO C. La fonctionnalité dérive d’une thèse de génie informatique de 2017.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
exception_t E {};                              // exception type
void f(...) {
	... throw E{}; ...                          // termination
	... throwResume E{}; ...             // resumption
}
try {
	f(...);
} catch( E e ; boolean-predicate ) {                    // termination handler
	// recover and continue
} catchResume( E e ; boolean-predicate ) {      // resumption handler
	// repair and return
} finally {
	// always executed
}

La surcharge de routines, d’opérateurs, de variables et de symboles est également à prendre en compte dans les extensions proposées par C-for-All. La fonctionnalité dérive des travaux d’une thèse de génie informatique de 1989.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// selection based on type and number of parameters
void f( void );                                // (1)
void f( char );                               // (2)
void f( int, double );                      // (3)
f();                                                // select (1)
f( 'a' );                                          // select (2)
f( 3, 5.2 );                                    // select (3)
 
// selection based on  type and number of returns
char f( int );                                  // (1)
double f( int );                              // (2)
[ int, double ] f( int );                    // (3)
char c = f( 3 );                              // select (1)
double d = f( 4 );                          // select (2)
[ int, double ] t = f( 5 );                 // select (3)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
int ++?( int op );                            // unary prefix increment
int ?++( int op );                            // unary postfix increment
int ?+?( int op1, int op2 );             // binary plus
int ?<=?( int op1, int op2 );           // binary less than
int ?=?( int * op1, int op2 );           // binary assignment
int ?+=?( int * op1, int op2 );         // binary plus-assignment
 
struct S { int i, j; };
S ?+?( S op1, S op2 ) {                 // add two structures
	return (S){ op1.i + op2.i, op1.j + op2.j };
}
S s1 = { 1, 2 }, s2 = { 2, 3 }, s3;
s3 = s1 + s2;                                  // compute sum: s3 == { 2, 5 }

Code :

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

1
2
short int MAX = ...;   int MAX = ...;  double MAX = ...;
short int s = MAX;    int i = MAX;    double d = MAX;   // select MAX based on left-hand type

Cette liste d’extensions n’est pas exhaustive et intègre d’autres éléments dont on perçoit mal l’impact réel sur des problèmes auxquels les utilisateurs du langage C font face. Illustration avec les instructions fallthru et fallthrough qui, au regard du code, sont des équivalents de goto.

Code :

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

1
2
3
4
5
6
7
8
9
choose ( ... ) {
  case 3:
	if ( ... ) {
		... fallthru;  // goto case 4
	} else {
		...
	}
	// implicit break
  case 4:

Code :

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

1
2
3
4
5
6
7
8
9
choose ( ... ) {
  case 3:
	... fallthrough common;
  case 4:
	... fallthrough common;
  common: // below fallthrough at case level
	...	 // common code for cases 3 and 4
	// implicit break
  case 4:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
choose ( ... ) {
  case 3:
	choose ( ... ) {
	  case 4:
		for ( ... ) {
			... fallthru common; // multi-level transfer
		}
		...
	}
	...
  common: // below fallthrough at case-clause level

Quoi qu’il en soit, C-for-All fait bien partie du paysage des nombreux remplaçants ou extensions du langage C. En génie logiciel, chaque projet impose de porter son choix sur un langage particulier en raison de l’existence de fonctionnalités que d’autres n’offriront pas. À chacun donc de juger et d’intégrer ce dernier à son flux de travail en fonction de la pertinence.

Source

uWaterloo

Votre opinion

Que pensez-vous de C-for-All ?

Quelles sont d’après vous les extensions qui sont les bienvenues ?

Quelles sont celles qui n’ont aucun impact sur la productivité ? Pourquoi ?

Voir aussi

Quel avenir pour le langage C ? Un développeur expérimenté fait ses adieux au langage et livre ses inquiétudes quant à son avenir

[codec_abc]

Ajouter des exceptions au langage C sans RAII, quelle bonne idée! Bonjour les crashs ou memory/ressources leak a tout va. Et le C est un des rares langages qu'il faut faire évoluer doucement. Pour moi le C est destiné aujourd'hui a des secteurs bien spécifiques ou sa simplicité apparente a plus de valeurs que sa productivité assez faible (en comparaison avec des langages de plus haut niveau). Bref non merci, laissez le C tel qu'il est.

[Gugelhupf]

Je suis déçu des features proposés par C-for-All, je trouve les features d'import et de paradigme objet léger de C2 bien plus intéressants.

[koala01]

Salut,

Je crois que C doit, comme tout langage, évoluer ou risquer d'être de plus en plus "mis au rencart"...

Mais je crois aussi que nous aurions tout à perdre à essayer de le faire évoluer trop vite, car c'est aussi un langage qui n'a aucun précédent. Et pour cause: il est plus ou moins reconnu comme... le père (ou l'aïeul) de tous les autres.

De plus c'est aussi le langage (de troisième génération s'entend) qui propose à la base le niveau d'abstraction le plus bas: avec moins d'abstraction que C, on écrit en assembleur.

Et le fait est que l'on aura toujours besoin d'un langage à très faible niveau d'abstraction, ne serait-ce que parce que l'informatique est (très) loin de se limiter aux PC de plus en plus puissants, équipés de windows ou de linux!!! L'informatique, c'est aussi tout un tas de "micro puces" que l'on peut programmer dans "une certaine mesure", mais qui n'ont pas la joie d'être soutenue par un système d'exploitation digne de ce nom, ou qui n'ont pas l'occasion d'attendre qu'une machine virtuelle ait pris le relais.

Or, pour cette partie (certains parleront sans doute de niche) de l'informatique, sans le C (même si C++ peut -- dans une certaine mesure -- prendre le relais), on n'a plus rien, si ce n'est l'assembleur...

Alors, nous pourrions envisager que "quelqu'un" développe un langage avec des caractéristiques fort semblable au C, en évitant (si possible) certains de ses affres, et que ce "quelqu'un" en fasse dont à l'ANSI ou à l'ISO. Peut-on rêver, ce langage *** pourrait *** être considéré --y compris par les développeurs C les plus intransigeants -- comme le digne successeur de C.

A ceci près qu'il y a toute la base de code écrite en C qui est purement phénoménale, qu'il faudra sans doute encore maintenir pendant des années. Ce qui fait que, quel que soit la qualité de ce nouveau langage hypothétique, il risque malgré tout d'avoir du mal à se faire sa "place au soleil"

[Neckara]

Attention aux  


Sinon, je détestes cette manie de vouloir réinventer la roue en permanence. Avoir 36 000 langages de programmation ne sert à rien.
Pourquoi ne pas utiliser/partir de ce qui existe déjà ? Pourquoi ne pas utiliser directement C++ ?


C'est comme pour générer de la documentation en JavaScript, on a 50 alternatives pour le faire, alors que Doxygen est utilisé pour les autres langages et marche très bien (et mieux que ces alternatives), au pire créer un plugin pour mieux gérer cela.

C'est comme les entreprises qui veulent héberger elles-même leurs propres services pour des raisons de sécurité... qui refont leur propre trucs ou choisissent des services obsolètes qui ne seront au final pas utilisées...


On déjà suffisamment de langages :

• Python
• C++
• LaTeX
• CSS
• JSON
• XML

Rien qu'avec cela on pourrait couvrir 99,99% des usages.

Regardez-moi ça, je parie que vous n'en connaissez même pas la grande majorité, et que la grande majorité est juste inutile.

[archqt]

Bonjour,
autant faire du C++ qui donne du code aussi rapide et léger que du C. Il suffit pour s'en convaincre de regarder des vidéos de conférences comparant les 2.
Bonne fin de journée

[Uther]

quatre raisons permettent de soutenir cette affirmation. Primo, n’en déplaise à ses détracteurs, C est encore largement utilisé. Secundo, il sera toujours nécessaire d’être à même de faire « joujou » de façon aisée avec le hardware et pour des tâches de ce type, le langage C continue de faire partie des premiers choix. Tertio, le langage est reconnu pour l’efficacité de son code source. Enfin, le langage se prête bien aux tâches de développement d’applications multiplateformes, ce à quoi les férus font souvent référence en parlant de portabilité.

- Primo, En effet C est largement utilisé un peu partout dans l'industrie pour tout ce qui est du bas niveau, et c'est une référence dans le domaine universitaire a cause d'UNIX. C'est sa principale qualité comme sont plus gros défaut : il est utilisé dans des domaines très conservateurs, ce qui explique qu'il peine tant a évoluer.

- Secundo et Tertio, Il est vrai que le C est très efficace et adapté au bas niveau, mais ça n'est pas le seul a pouvoir faire ça, il y en a d'autres qui sont tout autant capable comme le C++, le Nim ou le Rust par exemple.

- Enfin en ce qui concerne la portabilité, il faut reconnaitre qu'il existe un compilateur C pour quasiment toutes les architectures de processeur existantes, et que aucun langage ne peut prétendre en faire autant.
Mais si on regarde strictement du point de vue des spécificités du langage, le C est loin d'être ce qui ce fait de mieux. Sa norme est volontairement imprécise. Pour faire un programme C vraiment portable, il faut faire très attention a ce que l'on fait car beaucoup de chose vont réagir différemment en fonction de la plateforme. Si le C a pu être portable c'est surtout grâce a la norme POSIX et beaucoup d'huile de coude.

Cette liste d’extensions n’est pas exhaustive et intègre d’autres éléments dont on perçoit mal l’impact réel sur des problèmes auxquels les utilisateurs du langage C font face. Illustration avec les instructions fallthru et fallthrough qui, au regard du code, sont des équivalents de goto.

Je suppose que le but de "fallthru", comme pour les blocs avec label, c'est justement de pouvoir traiter le goto, qui est connu comme pouvant être abusé en C, comme une fonctionnalité déprécié. Du coup il faut remplacer les cas ou son usage se justifie encore par des syntaxes spécifiques.

Ajouter des exceptions au langage C sans RAII, quelle bonne idée!

L'article ne le précise pas, mais il y a aussi des constructeurs/destructeur, dont potentiellement moyen de faire de la RAII, avec ce langage.

Je suis déçu des features proposés par C-for-All, je trouve les features d'import et de paradigme objet léger de C2 bien plus intéressants.

Pour moi C2 était bâtard, il est certes plus propre au niveau de ce qu'il propose, mais ça se faisait au dépend de la compatibilité avec le C. Et quitte a avoir une syntaxe incompatible autant aller voir du coté de Rust ou Nim qui proposent bien plus qu'une petite amélioration du C.

Pour le coup C-for-All réussi a garder une meilleure compatibilité avec la syntaxe C actuelle que ce que proposait C2. Même si certains choix ne ne convainquent pas vraiment, surtout au niveau de la syntaxe (on sent la contrainte de l'héritage du C), il y a des fonctionnalité intéressantes.

Or, pour cette partie (certains parleront sans doute de niche) de l'informatique, sans le C (même si C++ peut -- dans une certaine mesure -- prendre le relais), on n'a plus rien, si ce n'est l'assembleur...

Non, il y a d'autre langages qui sont tout a fait capable d'en faire autant comme le C++, Nim ou Rust par exemple.

A ceci près qu'il y a toute la base de code écrite en C qui est purement phénoménale, qu'il faudra sans doute encore maintenir pendant des années. Ce qui fait que, quel que soit la qualité de ce nouveau langage hypothétique, il risque malgré tout d'avoir du mal à se faire sa "place au soleil"

C'est fou cette vision Highlander ("il ne peut en rester qu'un") des langages informatiques. A peu près tous les langages savent s'interfacer avec le C, particulièrement les langages bas niveau comme le C++/Nim/Rust. Il y a moyen d'introduire de nouveaux langages bas niveau sans avoir a tout réécrire.

[watchinofoye]

Après les hypothétiques remplaçants du C, l'hypothétique dénature du C (peut-être dans l'espoir d'éclipser le C pour mettre en avant un hypothétique remplaçant ?)...

"Leave C language alone "

[koala01]

Regardez-moi ça, je parie que vous n'en connaissez même pas la grande majorité, et que la grande majorité est juste inutile.

Peut être, justement, parce que nous n'en connaissons pas la grande majorité...

Il se peut donc, effectivement, que certains (bon, peut-être seulement un ou deux, ce qui serait déjà énorme ) puissent prendre le relais du C...

Mais, à part C++ (qui peut s'approcher énormément des cas d'utilisation de C, mais qui a quand même aussi un bon nombre d’incompatibilités avec lui), aucun de ceux que tu as cités ne peut prendre la "niche" du C.

Et, quand bien même, on dirait "merde" à la compatibilité -- ce qui pourrait à la fois faire le plus grand bien et le plus grand mal -- si on n'arrive pas avec un dossier béton qui démontre que l'on a pu faire avec un langage tout ce que C permet de faire, sans sacrifier les performances (car avec de meilleures, ca risque d'être dur ) mais avec moins de risques d'erreurs, moins de chausses trappes à gauche et à droite et (sans doute surtout) sans *** trop *** bousculer les habitudes des développeurs, j'ai bien peur que la sauce ne prenne jamais

[Aiekick]

Attention aux  


Sinon, je détestes cette manie de vouloir réinventer la roue en permanence. Avoir 36 000 langages de programmation ne sert à rien.
Pourquoi ne pas utiliser/partir de ce qui existe déjà ? Pourquoi ne pas utiliser directement C++ ?


C'est comme pour générer de la documentation en JavaScript, on a 50 alternatives pour le faire, alors que Doxygen est utilisé pour les autres langages et marche très bien (et mieux que ces alternatives), au pire créer un plugin pour mieux gérer cela.

C'est comme les entreprises qui veulent héberger elles-même leurs propres services pour des raisons de sécurité... qui refont leur propre trucs ou choisissent des services obsolètes qui ne seront au final pas utilisées...


On déjà suffisamment de langages :

• Python
• C++
• LaTeX
• CSS
• JSON
• XML

Rien qu'avec cela on pourrait couvrir 99,99% des usages.

Regardez-moi ça, je parie que vous n'en connaissez même pas la grande majorité, et que la grande majorité est juste inutile.

Python, c++ ok
Latex, je sais pas
mais css ? un simple langage descriptif rien a voir avec de la programmation
Json, une simple structure de donnée
Xml langage descriptif, comme le html, plus une structure de donné qu'un langage de programmation.

rien a voir avec le c donc... mais je suppose que c'est voulu ?

[Pyramidev]

Sinon, je détestes cette manie de vouloir réinventer la roue en permanence. Avoir 36 000 langages de programmation ne sert à rien.
Pourquoi ne pas utiliser/partir de ce qui existe déjà ? Pourquoi ne pas utiliser directement C++ ?

[...]

On déjà suffisamment de langages :

• Python
• C++
• LaTeX
• CSS
• JSON
• XML

Rien qu'avec cela on pourrait couvrir 99,99% des usages.

Je suis d'accord pour dire qu'il y a trop de langages, mais ta liste est trop restreinte :

• Python est accessible aux débutants et permet d'écrire du code concis, mais n'est pas performant. Cela conduit des chercheurs à coder deux fois la même chose : un prototype en Python puis un programme dans un langage plus performant, comme C++. On a donc besoin d'un langage avec les principaux avantages du Python, mais plus performant. Peut-être Julia.
• C++ est riche et performant. Mais, même avec une telle richesse, il est plus compliqué qu'il ne devrait et contient plus de pièges qu'il ne devrait. En outre, il est lent à compiler, surtout s'il y a trop de code dans les fichiers d'entête, ce qui restreint l'utilisation des templates dans un gros projet. On a donc besoin d'un meilleur C++, beaucoup plus rapide à compiler, plus simple à apprendre et, tant qu'à faire, encore plus riche. Peut-être le langage D. D'ailleurs, je me demande si ce dernier peut aussi remplacer Julia.
• Dans ta liste, je ne vois pas de langage qui supporte vraiment le paradigme fonctionnel comme Haskell. L'inconvénient de ce paradigme est qu'il est plus difficile à apprendre que la programmation orientée objet. Mais l'avantage est qu'il permet d'écrire du code beaucoup plus modulaire.

De manière générale, les langages au sommet du classement TIOBE ne sont pas assez bons. On a besoin de mieux.

Cela dit, les concepteurs de nouveaux langages ne devraient pas se contenter d'essayer de faire mieux que les langages au sommet du classement TIOBE. Ils devraient aussi, s'ils y arrivent, essayer de faire mieux que les langages moins connus qui ont du mal à s'imposer. Sinon, on augmente la liste des langages inutiles. Or, je pense que le C-for-All s'ajoute à cette liste.

[koala01]

C'est fou cette vision Highlander ("il ne peut en rester qu'un") des langages informatiques. A peu près tous les langages savent s'interfacer avec le C, particulièrement les langages bas niveau comme le C++/Nim/Rust. Il y a moyen d'introduire de nouveaux langages bas niveau sans avoir a tout réécrire.

Oh, si seulement c'était vrai (du moins pour C++, vu que Nim et rust, je connais pas)...

Je ne nie pas qu'il y aurait très certainement moyen de prendre une bonne part du code existant et de le filer "tel quel" à un "autre compilateur" (comprend un compilateur pour "un autre langage que le C") et de s'en sortir encore très raisonnablement, mais, pour ne parler que de C++ que je connais suffisamment, il ne faut pas oublier qu'il ne supporte qu'une partie de la norme C.

Non pas parce qu'il considère ce qu'il ne supporte pas comme "inutile", mais bel et bien à cause d'une incompatibilité réelle avec sa propre norme.

Alors, je ne sais pas exactement quelle est la proportion de C qui n'est pas supportée en C++ (et, quelque part, je m'en fous :p ) mais, même si ca ne devait être que de l'ordre de 1/100 ou de 1/1 000, je ne voudrais pas vraiment être le type qui devrait s'occuper de rendre le noyau linux compatible !

Et, surtout: même dans de si petites proportions, il faudrait combien de gars pour arriver à rendre la base de code (même en se limitant à celle qui est effectivement encore utilisée) compatible

Quand on voit que le seul bug de l'an deux mille a couté plus de 3 000 milliards de dollars pour être évité, combien couterait cette "petite mise à niveau" selon toi

[Pyramidev]

@koala01 : Uther ne parlait pas de compiler directement du code C avec un compilateur C++, Nim ou Rust, mais d'appeler du code compilé en C depuis du code écrit dans un autre langage, par exemple C++, Nim ou Rust.

[Uther]

@koala01> Bien évidement que si tu compiles du C directement avec un compilateur C++, tu vas avoir des problèmes. Les langage ont beau être proches, leur normes ne sont pas prévues pour être compatible.

Tu confonds interfacer et remplacer. Encore une fois, je ne parle pas de remplacer le C en mode "tout doit disparaitre".
Quand je parle d'interfacer, je veux dire que le code C qui n'a pas besoin de changement lourd restera compilé par un compilateur C. Mais que les nouveaux développement importants que l'on peut bien isoler peuvent être réalisés dans un autre langage qui s'interface avec le C via les mécanisme prévus pour, comme extern "C" en C++.

On peut ainsi introduire les nouveaux développement dans un nouveau langage, tout en continuant a travailler avec une base de code existante en C.

[Neckara]

Mais, à part C++ (qui peut s'approcher énormément des cas d'utilisation de C, mais qui a quand même aussi un bon nombre d’incompatibilités avec lui), aucun de ceux que tu as cités ne peut prendre la "niche" du C.

Python, c++ ok
Latex, je sais pas
mais css ? un simple langage descriptif rien a voir avec de la programmation
Json, une simple structure de donnée
Xml langage descriptif, comme le html, plus une structure de donné qu'un langage de programmation.

rien a voir avec le c donc... mais je suppose que c'est voulu ?

Le C ne permet pas de tout faire, c'est bien pour cela que j'ai cité une liste de langages. On a besoin de plusieurs langages pour plusieurs utilisations, mais pas de plusieurs clones d'un même langage.

Du JSON/XML pour des données formatées, CSS pour tout ce qui est design, Python pour tout ce qui est scripts, C++ pour les perfs, LaTeX pour de la rédaction de documents.

Je suis d'accord pour dire qu'il y a trop de langages, mais ta liste est trop restreinte

Ma liste est non-exhaustive, et bien sûr il faudrait regarder plus en détails.

D'ailleurs, il faudrait ajouter un langage de requête, e.g. SQL.

Python est accessible aux débutants et permet d'écrire du code concis, mais n'est pas performant. Cela conduit des chercheurs à coder deux fois la même chose : un prototype en Python puis un programme dans un langage plus performant, comme C++.

Je dois avouer ne pas avoir beaucoup creusé sur point là.

À voir déjà si les outils d'optimisations ainsi que le fait de réduire la complexité algorithmique ne sont pas suffisant. Est-ce aussi des contraintes liées au langage en lui-même, ou à ses implémentations d'interpréteurs ?

C++ est riche et performant. Mais, même avec une telle richesse, il est plus compliqué qu'il ne devrait et contient plus de pièges qu'il ne devrait.

As-tu des exemples en tête ?

En outre, il est lent à compiler, surtout s'il y a trop de code dans les fichiers d'entête, ce qui restreint l'utilisation des templates dans un gros projet.

Vivement les modules.

Dans ta liste, je ne vois pas de langage qui supporte vraiment le paradigme fonctionnel comme Haskell. L'inconvénient de ce paradigme est qu'il est plus difficile à apprendre que la programmation orientée objet. Mais l'avantage est qu'il permet d'écrire du code beaucoup plus modulaire.

On peut en effet l'ajouter si tu veux.

Cela dit, les concepteurs de nouveaux langages ne devraient pas se contenter d'essayer de faire mieux que les langages au sommet du classement TIOBE. Ils devraient aussi, s'ils y arrivent, d'essayer de faire mieux que les langages moins connus qui ont du mal à s'imposer. Sinon, on augmente la liste des langages inutiles. Or, je pense que le C-for-All s'ajoute à cette liste.

Je suis tout à fait d'accord.

De même, essayer d'avoir des syntaxes identiques, par exemple avoir du C++ avec une syntaxe de python serait pas mal et éviterait les problèmes d’accolades.
Et même plutôt que de proposer des nouveaux langages, proposer des sucres syntaxiques qui serait convertis en un langage-cible (e.g. C++ avec syntaxe python -> C++).

Et, surtout: même dans de si petites proportions, il faudrait combien de gars pour arriver à rendre la base de code (même en se limitant à celle qui est effectivement encore utilisée) compatible

Quand on voit que le seul bug de l'an deux mille a couté plus de 3 000 milliards de dollars pour être évité, combien couterait cette "petite mise à niveau" selon toi

Justement, quand on doit gérer que 5 ou 6 langages, c'est bien plus facile que si on devait en gérer 36 000.

[Pyramidev]

C++ est riche et performant. Mais, même avec une telle richesse, il est plus compliqué qu'il ne devrait et contient plus de pièges qu'il ne devrait.

As-tu des exemples en tête ?

Voici quelques exemples de pièges qui ne viennent pas de la richesse du langage, mais d'erreurs de conceptions, soit héritées du langage C (à cause de la rétrocompatibilité), soit ajoutées en C++ :

• Dans une classe, les variables membres sont accessibles même avant d'avoir été construites.
  Explication : Dans une classe MaClasse, si m_variable_membre_1 a été déclarée avant m_variable_membre_2, alors m_variable_membre_1 est initialisée avant m_variable_membre_2, quel que soit l'ordre dans lequel on les écrit dans le code du constructeur.
  Malgré cela, le code suivant compile :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  MaClasse() : m_variable_membre_2{}, m_variable_membre_1{m_variable_membre_2} {}
   
  // Le code ci-dessus équivaut à :
  // MaClasse() : m_variable_membre_1{m_variable_membre_2}, m_variable_membre_2{} {}
   
  // Donc on construit m_variable_membre_1 en lui passant en argument une donnée non initialisée !!!

• Quand un constructeur peut n'avoir qu'un seul paramètre, si on oublie le mot-clé explicit, alors on définit par mégarde une conversion implicite, ce qui affaiblit le typage. À la place, il aurait fallu un mot-clé implicit qu'on écrit uniquement si on décide consciemment de définir une conversion implicite.
• Quand une classe Base a un destructeur public non virtuel et qu'on définit une classe dérivée Deriv, ça compile. Mais, si on fait un delete (directement ou indirectement) d'un Base* qui pointe vers un objet Deriv, le comportement est indéterminé. Il aurait été préférable qu'on ait une erreur de compilation quand on fait un delete sur un Base* si Base est dérivable. Pour cela, il aurait fallu que C++98 permette de distinguer une classe dérivable d'une classe non dérivable. Mais il a fallu attendre C++11 pour avoir le mot-clé final.
• Par défaut, quand il le peut, le compilateur génère tout seul un constructeur de copie public et une affectation de copie publique, même si le destructeur a été redéfini, ce qui est un piège, parce que cela conduit souvent à libérer plusieurs fois la même ressource (exemple : double delete). Il aurait été préférable d'obliger l'utilisateur à les générer explicitement avec = default si le destructeur a été déclaré explicitement. Mais il a fallu attendre C++11 pour avoir = default. En pratique, ce piège concerne surtout ceux qui n'utilisent pas la règle du zéro, mais cela reste un piège.
• Quand on fait un delete d'un pointeur vers un type incomplet (typiquement une classe déclarée en avance), ça compile, mais le destructeur de cette classe ne sera pas appelé. De même, si cette classe a un opérateur delete spécifique, celui-ci ne sera pas appelé. Ce piège ne touche que ceux qui utilisent delete au lieu de std::unique_ptr, dont l'instanciation du deleter provoque une erreur de compilation si le type de la donnée pointée est incomplet, mais ça reste un piège.
• Dans un switch, oublier des case ne provoque aucune erreur de compilation, même si la valeur testée est un type énuméré. Ce problème est imposé par la rétrocompatibilité avec le langage C.
• En C++, quand on initialise une variable globale x à partir d'une variable globale y d'une autre unité de compilation, on n'a pas de garantie que y est initialisé avant x. En D, par contre, l'ordre des initialisations statiques est déterminé par l'ordre d'import des modules (lien). En C++, ce piège touche surtout ceux qui abusent des variables globales, mais ça reste un piège.
• Il y a trop de conversions implicites en booléens, ce qui affaiblit le typage. Si on combine ça avec le fait que l''opérateur = retourne une lvalue de même type que l'opérande de gauche au lieu de retourner void, cela démultiplie les risques d'erreurs, par exemple si on écrit par mégarde if(unEntier = unAutreEntier) au lieu de if(unEntier == unAutreEntier). C'est la faute du langage C.
• >> sur un entier signé strictement négatif a un implementation defined behaviour. C'est encore une bêtise héritée du langage C.

Une partie des problèmes ci-dessus sont palliés par les avertissements du compilateur. Mais, parfois, on récupère du mauvais code pour lequel les nouveaux avertissements du compilateur sont noyés dans une masse d'avertissements déjà existants. D'autres fois, on travaille avec un compilateur qui n'est pas assez bon et omet certains avertissements.

Voici aussi quelques exemples de complexité inutile qui ralentissent l'apprentissage du langage :

• Le mot-clé static a deux sens différents : durée de vie statique et lien interne. Il aurait fallu deux mot-clés différents : static et intern ou internal. En plus, static dans le sens de lien interne fait doublon avec les espaces de noms anonymes. Pour complexifier les choses, les variables globales constantes non volatiles non inlines ont un lien interne par défaut, alors que ce n'est pas le cas en C.
• Il est possible de surcharger l'opérateur unaire &. Alors, en programmation par template, on utilise la bidouille std::adressof.
• Il y a le problème du Most vexing parse.

Vivement les modules.

C'est vrai que ce sera un grand pas en avant.

De même, essayer d'avoir des syntaxes identiques, par exemple avoir du C++ avec une syntaxe de python serait pas mal et éviterait les problèmes d’accolades.

Personnellement, je pense qu'un langage idéal devrait laisser le choix entre les deux, comme le fait Haskell.
Par exemple, avec Haskell, voici deux bouts de code qui font la même chose : un avec des point-virgules et des accolades et un autre avec de l'indentation :

Code :

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

1
2
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
liftM2 f m1 m2 = do { x1 <- m1; x2 <- m2; return (f x1 x2) }

Code :

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

1
2
3
4
5
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
liftM2 f m1 m2 = do
    x1 <- m1
    x2 <- m2
    return (f x1 x2)

Edit 2018-03-26-20h52 : ajout d'un petit paragraphe sur les avertissements du compilateur.
Edit 2018-03-26-22h01 : correction de fautes de français.

[Invité]

Personnellement, je pense qu'un langage idéal devrait laisser le choix entre les deux, comme le fait Haskell.
Par exemple, avec Haskell, voici deux bouts de code qui font la même chose : un avec des point-virgules et des accolades et un autre avec de l'indentation :

Code :

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

1
2
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
liftM2 f m1 m2 = do { x1 <- m1; x2 <- m2; return (f x1 x2) }

Code :

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

1
2
3
4
5
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
liftM2 f m1 m2 = do
    x1 <- m1
    x2 <- m2
    return (f x1 x2)

mouais, enfin la "vraie" syntaxe de ce code c'est quand même :

Code :

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

1
2
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
liftM2 f m1 m2 = m1 >>= (\ x1 -> (m2 >>= (\x2 -> return $ f x1 x2)))

et question lisibilité, ça se discute...

[Pyramidev]

La version sans le sucre syntaxique de la do-notation est effectivement moins lisible, mais où veux-tu en venir ?

[Invité]

La version sans le sucre syntaxique de la do-notation est effectivement moins lisible, mais où veux-tu en venir ?

Nulle part, c'était juste pour la boutade car Haskell est plus souvent cité comme un langage étrange avec une syntaxe exotique.

[Madmac]

Je suis d'accord pour dire qu'il y a trop de langages, mais ta liste est trop restreinte :
[LIST][*]Python est accessible aux débutants et permet d'écrire du code concis, mais n'est pas performant. Cela conduit des chercheurs à coder deux fois la même chose : un prototype en Python puis un programme dans un langage plus performant, comme C++. On a donc besoin d'un langage avec les principaux avantages du Python, mais plus performant. Peut-être Julia.

La lenteur d'un interpréteur n'a pas que des désavantages. La vitesse est souvent un arbre qui cache la forets, parce qu'un langage rapide a tendance à être plus permissive pour du code sub-optimal. Si votre code est suffisamment performant sur un langage interprété, vous avez de la marge de manœuvre si la demande augmente.

Julia semble un bon candidat, mais je ne sais pas s'ils ont adopté l'unicode. Crystal me semble être déjà un choix prometteur. À moins, d'utiliser les particularités d'un langage interprété. il exécute en général le code en Ruby 5 fois plus vite.