Le C au futur

Version imprimable

08/05/2007, 17h30
diogene

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.
08/05/2007, 17h32
DaZumba

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.
08/05/2007, 17h40
souviron34

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...
08/05/2007, 17h47
Jean-Marc.Bourguet

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.
08/05/2007, 17h58
DaZumba

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 !
08/05/2007, 18h39
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...).

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 ?
08/05/2007, 18h54
Emmanuel Delahaye

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
08/05/2007, 22h08
DaZumba

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.
08/05/2007, 22h23
Emmanuel Delahaye

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...
08/05/2007, 22h51
souviron34

Citation:

Envoyé par Emmanuel Delahaye

Exactement. Les dinosaures ont mal fini...

et les humains en prennent assez rapîdement le chemin :aie: ;)
09/05/2007, 09h13
kromartien

Quel est la progression du C++ vis à vis du C ?

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 ?
09/05/2007, 09h28
Jean-Marc.Bourguet

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.
09/05/2007, 09h35
Emmanuel Delahaye

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)...
09/05/2007, 09h55
kromartien

@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 ...
09/05/2007, 10h10
Franck.H

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 !
09/05/2007, 10h15
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 ?
09/05/2007, 10h25
Jean-Marc.Bourguet

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.
09/05/2007, 10h25
Franck.H

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 ;)
09/05/2007, 10h40
Jean-Marc.Bourguet

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.
09/05/2007, 11h44
souviron34

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
09/05/2007, 11h52
reptils

J'ai une question, je fais pas mal de calcul numerique pour ma these de physique et j'aimerais avoir un eclaircissement sur le MPI et les threads. Je fais uniquement du séquentiel donc je ne suis pas concerner par les multicore, mais j'aimerais comprendre c'est quoi la différence entre les threads (de pthread en c) et MPI?
l'un utilise vraiment explicitement les multiproc et l'autre juste des multi tache sur mono ou multi proc? ou je me gourre complet?
09/05/2007, 13h02
Médinoc
Les deux peuvent utiliser le multi-processeur, mais la différence est dans la séparation des données.
- En multi-thread, il n'y a qu'un seul processus (mais chaque thread peut tourner sur son propre processeur, si c'est le kernel qui s'en occupe comme sous Win32), toutes les données sont partagées (même si chaque thread a sa propre pile, un pointeur sur la pile d'un autre thread reste valide).
- MPI, c'est du multi-processus, donc mémoires séparées, et les échanges se font par "messages".
09/05/2007, 13h29
gege2061

Citation:

Envoyé par Jean-Marc.Bourguet

le C++0X va importer pas mal des ajouts de C99

Bizarrement le C99 était prévu pour minimiser les différences entre le C et le C++ et finalement, c'est le C++ qui va évoluer pour s'adapter :cfou:

Citation:

Envoyé par Jean-Marc.Bourguet

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.

Y a déjà eu une extension qui a été approuvée : Bounds-checking interfaces (n1147), mais ça serait un bon début que le C99 soit implémenté par les compilateurs les plus utilisés !
09/05/2007, 13h38
Jean-Marc.Bourguet

Citation:

Envoyé par gege2061

Bizarrement le C99 était prévu pour minimiser les différences entre le C et le C++ et finalement, c'est le C++ qui va évoluer pour s'adapter :cfou:

Ca n'a certainement pas ete un critere dans l'adoption de chose comme inline et complex (deux cas ou C99 introduit quelque chose de disponible en C++ de maniere incompatible).

Citation:

Y a déjà eu une extension qui a été approuvée : Bounds-checking interfaces (n1147),

C'est un TR. Rien ne dit que ce sera integre dans une prochaine version de la norme. (Toute la lib de TR1 en C++ par exemple ne se retrouvera pas dans C++0X).
09/05/2007, 14h28
Jean-Marc.Bourguet

Citation:

Envoyé par souviron34

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é ?

MPI est une approche possible sur certains programmes mais manque de generalite.

Citation:

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.

Je ne vois aucun rapport entre threads et COMMON.
09/05/2007, 14h37
souviron34

Citation:

Envoyé par Jean-Marc.Bourguet

MPI est une approche possible sur certains programmes mais manque de generalite.

....

Je ne vois aucun rapport entre threads et COMMON.

Pour MPI, ça a été fabriqué POUR le parallèlisme, donc je ne vois pas l'intérêt de développer des extensions à des langages non faits pour. Qu'on modifie MPI si il ne répond pas à toutes les attentes, cela a plus de sens...

En ce qui concerne le pbe threads/common, il me semble avoir compris (je ne sais pas, juste d'après ce que j'ai lu sur le forum, puisque jamis utilisé les threads) que l'argument était le partage des données. Ce que fait exactement le common, y compris avec la synchronisation...
09/05/2007, 14h44
Médinoc

Il y a aussi le fait qu'avoir un seul processus multi-thread est plus léger qu'avoir N processus mono-thread.
D'abord à la création, mais aussi à l'exécution : Les commutations de contexte sont moins couteuses d'un thread à l'autre que d'un processus à l'autre.
De plus, aucune sérialisation n'est nécessaire pour communiquer des données d'un thread à l'autre: Tous les pointeurs valides dans un thread sont valides dans tous les autres...
09/05/2007, 14h55
Jean-Marc.Bourguet

Citation:

Envoyé par souviron34

Pour MPI, ça a été fabriqué POUR le parallèlisme, donc je ne vois pas l'intérêt de développer des extensions à des langages non faits pour. Qu'on modifie MPI si il ne répond pas à toutes les attentes, cela a plus de sens...

MPI a ete concu pour parallelliser un certain type d'application (en simplifiant, du calcul sur des matrices avec chaque noeud qui fait ce qu'il faut sur sa partie de matrice). Si tes appli rentrent dans cette classe, c'est bien. Sinon, ce n'est meme pas un debut d'architecture repartie.

Citation:

En ce qui concerne le pbe threads/common, il me semble avoir compris (je ne sais pas, juste d'après ce que j'ai lu sur le forum, puisque jamis utilisé les threads) que l'argument était le partage des données. Ce que fait exactement le common, y compris avec la synchronisation...

Ou Fortran a fortement change (ce qui est le cas, mais j'aimerais confirmation que les changements portent aussi sur ca, ce qui m'etonne), ou COMMON ce n'est que des variables globales sans meme une verification du type.
09/05/2007, 15h24
souviron34
Citation:

Envoyé par Jean-Marc.Bourguet

MPI a ete concu pour parallelliser un certain type d'application (en simplifiant, du calcul sur des matrices avec chaque noeud qui fait ce qu'il faut sur sa partie de matrice). Si tes appli rentrent dans cette classe, c'est bien. Sinon, ce n'est meme pas un debut d'architecture repartie.

Je m'en suis servi sur des problèmes n'ayant rien à voir avec ça...

Pour plus d'info http://www-unix.mcs.anl.gov/mpi/

Extraits des buts :

Citation:

The goal of the Message Passing Interface, simply stated, is to develop a widely used standard for writing message-passing programs. As such the interface should establish a practical, portable, efficient, and flexible standard for message passing.
Citation:
The main advantages of establishing a message-passing standard are portability and ease-of-use. In a distributed memory communication environment in which the higher level routines and/or abstractions are build upon lower level message passing routines the benefits of standardization are particularly apparent. Furthermore, the definition of a message passing standard, such as that proposed here, provides vendors with a clearly defined base set of routines that they can implement efficiently, or in some cases provide hardware support for, thereby enhancing scalability.

The goal of the Message Passing Interface simply stated is to develop a widely used standard for writing message-passing programs. As such the interface should establish a practical, portable, efficient, and flexible standard for message passing.

A complete list of goals follows.

Design an application programming interface (not necessarily for compilers or a system implementation library).
Allow efficient communication: Avoid memory-to-memory copying and allow overlap of computation and communication and offload to communication co-processor, where available.
Allow for implementations that can be used in a heterogeneous environment.
Allow convenient C and Fortran 77 bindings for the interface.
Assume a reliable communication interface: the user need not cope with communication failures. Such failures are dealt with by the underlying communication subsystem.
Define an interface that is not too different from current practice, such as PVM, NX, Express, p4, etc., and provides extensions that allow greater flexibility.
Define an interface that can be implemented on many vendor's platforms, with no significant changes in the underlying communication and system software.
Semantics of the interface should be language independent.
The interface should be designed to allow for thread-safety.
Citation:

Envoyé par Jean-Marc.Bourguet

Ou Fortran a fortement change (ce qui est le cas, mais j'aimerais confirmation que les changements portent aussi sur ca, ce qui m'etonne), ou COMMON ce n'est que des variables globales sans meme une verification du type.

Absolument pas.... Je crois que tes souvenirs sont flous..

D'une part, en ce qui concerne la vérification des types, si on se place en Fortran, les COMMON ne sont accessibles que via les BLOCK DATA, qui définissent les variables, leurs types, leur ordre, leurs dimensions, etc.. depuis les premières définitions de Fortran

D'autre part, le mécanisme par lequel ces COMMON marchent sont par l'écriture PHYSIQUE sur le/les secteurs disques définis par l'OS comme étant commun(s) à tous. Je le répète, ce qui est accessible via l'nstruction PSECT en assembleur. Et par conséquent, même si cela n'est pas documenté très fortement, accesible à tous les langages (voir la rubrique de Barnard Cassagne pour le C http://c.developpez.com/cours/bernar...00000000000000 ou en assembleur VMS par exemple http://h21007.www2.hp.com/dspp/files...rm/lrm0598.htm ou l'équivalent sous Windows http://msdn2.microsoft.com/fr-fr/lib...x6(VS.80).aspx).
09/05/2007, 15h50
DaZumba

<hs>

Citation:

Envoyé par souviron34

Absolument pas.... Je crois que tes souvenirs sont flous..

Euh, en Fortran, un common block, c'est le moyen d'avoir des variables globales. Cela definit un segment de memoire nomme qui est accessible par toutes les routines du programme qui importent ce bloc. Rien d'autre. Depuis Fortran 90, il est deconseille d'utiliser des common. Ils sont remplaces par les modules.
</hs>
09/05/2007, 16h26
souviron34

Je suis d'accord avec toi, c'est devenu fortement déconseillé. Cependant, il y a 2 usages du COMMON :

1) déclarer des variables communes dans UN programme :

ce que tu cites (avec d'ailleurs applications entre C et Fortran : http://www.nersc.gov/vendor_docs/int...1/pgwuscom.htm

2) partager des données communes parmi PLUSIEURS programmes.

Cela fait trop longtemps que j'ai pratiqué pour me souvenir, mais je suis quasi-sûr que lorsqu'on définit des "BLOCK DATA", ceux-ci sont PHYSIQUEMENT stockés sur le disque (et accessibles par d'autre langages et/ou programmes).

Je me souviens l'avoir fait en assembleur sur un PDP.

Mais enfin, le fond du problème n'était pas là. C'était de dire qu'il est CERTAIN que n'importe quel OS réserve une place PHYSIQUE sur le disque pour ses opérations et data. Et qu'il y a forcément moyen d'y accéder.
09/05/2007, 16h54
DaZumba

<hs>

Citation:

Envoyé par souviron34

2) partager des données communes parmi PLUSIEURS programmes.

Faire de l'IPC en utilisant des COMMON BLOCK est effectivement possible, mais c'est acrobatique. Avec gfortran, on peut forcer l'adresse a laquelle le bloc va se trouver. Sous HP-UX, on a la directive SHARED_COMMON. Bref, c'est super pas portable...
</hs>

Citation:

C'était de dire qu'il est CERTAIN que n'importe quel OS réserve une place PHYSIQUE sur le disque pour ses opérations et data. Et qu'il y a forcément moyen d'y accéder.

La gestion de la memoire a tellement evoluee depuis la Grande Epoque que rien n'est certain. Les OS modernes utilisent des MMU, donc cela me semble difficile.
09/05/2007, 17h00
souviron34

Citation:

Envoyé par DaZumba

<hs>

Faire de l'IPC en utilisant des COMMON BLOCK est effectivement possible, mais c'est acrobatique. Avec gfortran, on peut forcer l'adresse a laquelle le bloc va se trouver. Sous HP-UX, on a la directive SHARED_COMMON. Bref, c'est super pas portable...
</hs>

La gestion de la memoire a tellement evoluee depuis la Grande Epoque que rien n'est certain. Les OS modernes utilisent des MMU, donc cela me semble difficile.

:D :D sans parler de grande époque....

que ce soit sur les systèmes *n*x (dans /tmp au minimum, dans /var, et dans d'autres fichiers (comme /etc ) des données sont physiquement partagées (exemple avec /etc/services)..