Le C au futur

Puisqu'un débat sur ce forum semble accorder une longue vie au langage C, je pose la question :

- Comment souhaiteriez vous qu'il évolue dans le futur ?

Pour ma part, ce que je regrette le plus souvent, est l'absence d'un mécanisme constructeur/ destructeur. Sans révolutionner le langage ni en faire un sous-C++ ou un langage oo, ce simple apport constituerait à mon avis un progrès réel dans l'écriture et la fiabilité des programmes. Ce serait, à mon sens, plus utile que certaines "récentes" innovations comme les VLA auxquels je ne voie pas un intérêt spécialement palpitant, en tout cas pas à la mesure des difficultés qu'il semble y avoir à les implanter.

Citation:

---

Envoyé par diogene

Comment souhaiteriez vous qu'il évolue dans le futur ?

---

A priori, il n'evoluera plus. Le comite de standardisation s'est mis en standby. Il ne fera plus que des corrections techniques.

je ne vois pas l'intérêt d'un constructeur destructeur....

Soit on prend un langage objet, soit on n'en prend pas. Et un des avantages de ne pas en prendre est de ne pas être contraint par la syntaxe des LOO.

Et de plus, très souvent, pour de grosses applications, il est possible que la programmation comme ceci rende les choses plus compliquées.

Et enfin, il est tellement simple de faire l'équivalent...

Citation:

---

Envoyé par diogene

- Comment souhaiteriez vous qu'il évolue dans le futur ?

---

Je n'ai pas tellement réfléchit à comment je désire qu'il évolue. Mais l'opinion du comité c'est l'inclusion d'extension courante. Voici un document de travail sur le sujet: http://www.open-std.org/jtc1/sc22/wg...docs/n1229.pdf.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Mais l'opinion du comité c'est l'inclusion d'extension courante.

---

Ah, le comite travaille encore alors ! Si c'est le cas, je vote pour typeof !

La première réponse de DaZumba avait de quoi mettre à bas l'optimisme des programmeurs C : un langage qui n'évolue plus est destiné à disparaître (ou il est désuet ou il est parfait, et même dans ce cas...).

Ma question n'est pas "comment évoluera" (on n'est pas devin) mais "comment souhaiteriez vous qu'il évolue"

souviron34

Citation:

---

Soit on prend un langage objet, soit on n'en prend pas.

---

Je crois qu'il faut largement plus qu'un constructeur pour faire d'un langage un langage OO. Ce n'était pas mon intention (comme je l'avais prudemment signalé).
Que proposes-tu ?

Citation:

---

Envoyé par diogene

- Comment souhaiteriez vous qu'il évolue dans le futur ?

Pour ma part, ce que je regrette le plus souvent, est l'absence d'un mécanisme constructeur/ destructeur.

---

Boaf...

http://emmanuel-delahaye.developpez.com/tad.htm

Mon générateur de code se charge du reste...

Nombreux exemples ici :
http://emmanuel-delahaye.developpez.com/clib.htm

Citation:

---

Envoyé par diogene

La première réponse de DaZumba avait de quoi mettre à bas l'optimisme des programmeurs C : un langage qui n'évolue plus est destiné à disparaître (ou il est désuet ou il est parfait, et même dans ce cas...).

---

Le problème c'est que la situation est un peu bloquée. Si l'on souhaite que le C reste le langage petit et léger qu'il est, il n'y a pas trente-six solutions : il faut cesser de l'étendre. Egalement, le C++ existe et il n'est absolument pas nécessaire d'en écrire un deuxième. Les extensions listées dans le document donné par Jean-Marc sont intéressantes (mention spéciale, en ce qui me concerne, à typeof et les mécanismes d'exception). Mais c'est du raffinement.

Citation:

---

Envoyé par DaZumba

Le problème c'est que la situation est un peu bloquée. Si l'on souhaite que le C reste le langage petit et léger qu'il est, il n'y a pas trente-six solutions : il faut cesser de l'étendre.

---

Exactement. Les dinosaures ont mal fini...

Citation:

---

Envoyé par Emmanuel Delahaye

Exactement. Les dinosaures ont mal fini...

---

et les humains en prennent assez rapîdement le chemin :aie: ;)

Je voudrai savoir quelle est la part de C dans le C++ ? Car C ... ++ , sans mauvaise blague.
En fait, C++ augmente les potentialités et la vitesse d'écriture du code (car C++) du langage C, mais dans quelle mesure sont-ils apparentés ?

Et concrètement, est ce que C ++ n'est pas l'avenir du C, au sens où il s'agit d'un langage hérité ?

Et finalement, quel est l'avantage du C++ par rapport au C ?

Demander ce qu'est l'avenir du C revient essentiellement à se demander quelle a été l'évolution de son rôle au sein des autres langages, puisqu'il ne s'agit pas d'un langage jeune, et que il a joué tous les rôles qui lui ont été assignés (portable, léger, rapide, proche de la machine et haut-niveau, écriture des systèmes d'exploitation, ...) .

Demander quel est l'avenir du C revient à se demander soit :
*si il y aurait autre chose pour le remplacer
*s'il était possible d'étendre ses domaines d'applications.

Ensuite pour revenir aux remarques judicieuses écrites plus haut, le C est le C, inutile de vouloir en faire quelque chose qu'il n'est pas. Ses applications sont bien définies, quelles seraient donc des utilisations possibles du C qui ne seraient pas réalisées déjà par d'autres langages ?

Citation:

---

Envoyé par Emmanuel Delahaye

Exactement. Les dinosaures ont mal fini...

---

Parce qu'ils n'ont pas su s'adapter aux conditions changeantes. L'immobilisme est aussi un probleme.

La condition changeante que je vois est qu'on a epuise la possibilite d'extraire des perfs d'un flux unique d'instructions; certains arguent qu'on est deja alle trop loin dans cette voie et que les perfs dont sont capables les processeurs ne sont atteignables que sur des charges de moins en moins repandues: sur les autres le processeur passe son temps a attendre la memoire.

L'evolution est donc vers le parallelisme. Et la sincerement le modele semantique du C est mal barre. C'est quelque chose qui traditionnellement etait fait par le comite C et recupere ensuite par le comite C++, quasiment tel quel. Mais l'initiative a change de comite -- le comite C++ travaille sur un modele plus adapte au parallelisme et il n'est pas impossible que ce travail soit recupere par le comite C. Est-ce que ce sera suffisant pour assurer la perenite de ces langages dans le "mainstream" ou bien seront-ils petit a petit reduits a des niches ou meme a la disparition, je n'en sais rien. Il n'est pas impossible que les langages imperatifs posent trop de problemes fondamentaux sur ces questions et que ce soit, enfin diront certains, l'heure des langages fonctionnels.

Citation:

---

Envoyé par kromartien

Je voudrai savoir quelle est la part de C dans le C++ ? Car C ... ++ , sans mauvaise blague.
En fait, C++ augmente les potentialités et la vitesse d'écriture du code (car C++) du langage C, mais dans quelle mesure sont-ils apparentés ?

---

Ils étaient apparentés quand Bjarne Stroustrup a inventé "C with classes". Ensuite, ces langages ont divergé et C++ est devenu un langage à part entière qui ne revendique pas son héritage, contrairement à Objective-C (qui a malheureusement un syntaxe assez étrange...)

Citation:

---

Demander quel est l'avenir du C revient à se demander soit :
*si il y aurait autre chose pour le remplacer

---

Non.

Citation:

---

*s'il était possible d'étendre ses domaines d'applications.

---

Ils sont déjà infinis.

C'est un langage de base qui sert à construire tout le reste. Il ne peut rien lui arriver et il sera là dans 100 ans... C'est comme si on disait "quel est l'avenir du langage machine ?"...

... sauf révolution technologique majeure, ou intervention des Asgards ou des Vulcains...

EDIT : Le parallélisme, oui, OK. C'est une évolution que pourrait intégrer le C, mais le système est censé se dépatouiller avec, non ?

Et puis intégrer POSIX.1 (voire plus) au langage C (quand c'est possible)...

@Emmanuel Delahaye : Merci beaucoup pour cette réponse.

@Jean-Marc.Bourguet : Pour reprendre le sujet de l'exploitation du parallélisme ? Je ne comprends pas pourquoi le modèle sémantique du C est mal barré pour le parallélisme. N'est ce pas le noyau qui gère les processus ?

Pour moi l'utilisation d'un parallélisme à deux cœurs, ce serait un type qui fait de la couture et l'autre au comptoir qui attend les clients. S'il n'y a pas de clients, le caissier dit à l'autre : "Pas la peine de t'échiner, là y a pas de client" .

Mais en C il y a des threads et des processus parallèles je crois. C'est le noyau qui répartit la charge de travail au processeur, pas le programme qui utilise telle ou telle propriété matérielle spécifique. La compilation peut être, mais pas le langage.

Pour les défauts sémantiques du C, je connais peu de langages, mais aucun qui ait des spécificités propres aux noyaux à processeurs double-cœur. Dire que l'utilisation du C est impropre aux noyaux double-coeurs, euh :koi: Ça existe les langages spéciaux pour double cœurs ? les noyaux double cœur oui, mais le langage ? Un langage a ses possibilités, et encore faut-il les connaître, mais pour le C c'est l'utilisation d'un compilateur efficace et rapide qui lui permet d'être un bon langage compilé. Sa conception au service des systèmes d'exploitation est bien ce qui fait de lui un langage rapide et portable.

C'est la description qui en est faite, alors comment pouvez vous prétendre qu'il est impropre aux systèmes double coeurs ?

A mon avis, les processeurs double-cœur, c'est pas une idée de la dernière pluie, j'imagine bien que certaines personnes ont du y penser avant qu'ils apparaissent dans les ordinateurs actuels, donc ...

Citation:

---

Envoyé par DaZumba

A priori, il n'evoluera plus. Le comite de standardisation s'est mis en standby. Il ne fera plus que des corrections techniques.

---

Bin j'espère, je n'utilise déjà pas le C99 :lol: Et par ailleurs, j'ai pas envie qu'il évolue, je l'aime comme il est, je peut déjà faire ce que je veux avec en l'état actuel du C89/C90 alors pourquoi plus !

avec -pedantic, gcc dit tout le temps que ce n'est pas conforme à C90, comme par exemple mélanger les déclarations et le code. Je crois que si on fait une fonction qui calcule par exemple pi, "double comput_PI(void);" , on n'a pas le droit de faire "double PI=comput_PI();" :
Warning; Mixed declaration and code.
avec malloc c'est pareil ?

Bref, C90 c'est mieux que C99 où c'est juste quelques Warnings qui disparaissent entre les deux, donc une structuration du code mieux contrôlée ?

Citation:

---

Envoyé par Emmanuel Delahaye

Ils étaient apparentés quand Bjarne Stroustrup a inventé "C with classes". Ensuite, ces langages ont divergé et C++ est devenu un langage à part entière qui ne revendique pas son héritage

---

Les langages ont diverge mais il y a eu (et continue d'avoir -- la clarification du modele des points de sequencement faite pour le C++ a des chances de se retrouver en C; le C++0X va importer pas mal des ajouts de C99) des influences dans les deux sens. Certains -- et j'en fais partie -- regrettent que la compatibilite ne soit pas plus un facteur; mais la "faute" de mon point de vue est des deux cotes.

Citation:

---

Envoyé par kromartien

avec -pedantic, gcc dit tout le temps que ce n'est pas conforme à C90, comme par exemple mélanger les déclarations et le code. Je crois que si on fait une fonction qui calcule par exemple pi, "double comput_PI(void);" , on n'a pas le droit de faire "double PI=comput_PI();" :
Warning; Mixed declaration and code.
avec malloc c'est pareil ?

Bref, C90 c'est mieux que C99 où c'est juste quelques Warnings qui disparaissent entre les deux, donc une structuration du code mieux contrôlée ?

---

Le fait qu'il y ai ds warnings en plus implique forcément des ajouts ou évolutions, comme par exemple l'interdiction de faire une déclaration de variable en milieu de code, ceci contribu par la même occasion à une meilleure structuration du code comme tu l'as si bien dit ;)

Citation:

---

Envoyé par kromartien

Mais en C il y a des threads

---

Non, et c'est bien le probleme. La norme C (comme la norme C++98) ignore totalement les threads. La norme C++0X va en ajouter et ca pose pas mal de problemes de definition -- quelles sont les actions d'une thread qui sont visibles par une autre? Le modele base sur les points de sequencement est a mettre a jour dans cette optique et il faut s'attaquer a ses imprecisions...

Citation:

---

comment pouvez vous prétendre qu'il est impropre aux systèmes double coeurs?

---

Double coeurs ou bi-processeur, ca ne change rien. Et ma remarque plus generale n'est pas dans le cadre d'un bi-pro -- ou les techniques actuelles fonctionnent et le travail fait pour le C++ suffit -- mais dans l'evolution. On est arrive au bout de ce qu'on sait faire pour exploiter du mono-thread; et meme un peu au dela pour certaines charges (Sun a fait Niagara -- 8 coeurs a 4 threads chacun, mais moins performant que d'autres de ses processeurs actuels en monothread -- parce que ces charges ont une importance) et la seule voie visible d'evolution est l'augmentation du parallelisme hors du flux d'instruction. Avec quelques coeurs -- disons 8 si on veut fixer un nombre -- on va exploiter le parallelisme existant facilement exploitable -- les processus, les threads d'appli deja multi-threads, ce qui est facilement mettable en multi-thread. Pour le reste -- hors quelques appli particulieres -- il va falloir changer completement le type d'architecture, logicielle et hardware.

Citation:

---

A mon avis, les processeurs double-cœur, c'est pas une idée de la dernière pluie, j'imagine bien que certaines personnes ont du y penser avant qu'ils apparaissent dans les ordinateurs actuels, donc ...

---

Il y a des machines multi-processeurs depuis longtemps. Des systemes mono-CPU mais avec des processeurs dedies aux IO (les channels des mainframe IBM) depuis au moins les annees 60. Des multi-CPU a memoire partagee depuis les annees 70. Je n'ai pas d'exemple en tete, mais je suppose que des multi-CPU a memoire non partagee ont du exister avant.

En ce qui concerne le parallèlisme, je ne suis pas franchement convaincu...

A mon avis, comme c'était (cela fait 17 ans que je n'ai pas regardé, donc je ne sais pas si c'est toujours le cas) sur les Silicon Graphics, et aussi avec VMS, ce serait plutôt de l'ordre du système d'exploitation de fournir une variable (environnement ?) donnant le nombre de processeurs. Et donc simplement un paramètrage de boucles etc.. en fonction de cette variable.
Le changement dû à du multi-processeurs ou du parallèlisme serait donc extrêmement réduit sur le langage.

D'autre part, MPI fait ça très bien, et s'intégre parfaitement au C ou au Fortran. Pourquoi vouloir inventer quelque chose d'autre, alors que MPI est largement utilisé ?


C'est d'ailleurs la même chose pour les threads... A moins qu'il y ai eu une évolution des OS que je n'ai pas suivi, la fonctionalité recouverte est exactement identique aux COMMON en Fortran, disponibles également en Pascal, il me semble également (mais mes explorations dans ce domaine remontent à loin) en C, et en assembleur via les PSECT, associée aux sémaphores globaux. Car, détrompez-moi si je dis une bêtise, mais TOUS les OS réservent une partie PHYSIQUE du disque pour des données communes.

8O