Question sur la compilation

Jean-Marc Bourguet

07/06/2004 à 11:49

writes:

Loïc Joly wrote in message
news:<c9vsuo$6jr$...
Jean-Marc Bourguet wrote:

Loïc Joly writes:

A moins que ce soit ma lecture du standardese qui soit déficiente,
"Library components are linked to satisfy external references to
functions and objects not defined in the current translation." me
semble un peu vague.

J'ai toujours compris ce "Library" comme faisant reference a la
bibliotheque standard.

Tiens, intéressant. Si c'est le cas, le concept de bibliothèque
utilisateur n'est plus seulement très vaguement défini par la
norme, mais il lui est totalement étranger.

D'autres avis là dessus ?

C'est que c'est loin d'être clair, et que l'interprétation de
Jean-Marc est tout à fait possible.

Il y a un "user-defined library" en 3.2/3 et c'est la seule occurence
(hors notes, jusqu'au chapitre 17) que j'ai trouvee ou il est clair
que la possibilite de bibliothèques autre que standard est envisagee.

Every program shall contain exactly one definition of every
non-inline function or object that is used in that program; no
diagnostic required. The definition can appear explicitly in the
program, it can be found in the standard or a user-defined
library, or (when appropriate) it is implicitly defined.

(En ce qui concerne la terminologie, je prefere les "shared object" de
Unix aux "DLL" de Windows car ca ne se comporte absolument pas comme
les autres bibliotheques du point de vue traite dans la discussion.)

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Alain Naigeon

07/06/2004 à 11:50

"Jean-Marc Bourguet" a écrit dans le message news:

writes:

"Michel Michaud" wrote in message
news:<C82wc.120883$...

Peut-être le mieux alors, c'est « linker ». Au moins comme ça, on
est sûr que tout le monde nous comprend:-).

Non, le mieux est « éditeur de liens ». Comme ça, on parle français et
on utilise la bonne traduction...

Et « faire une édition de liens », ou « éditer des liens », plutôt que
« linker » ?

J'utilise « lier » quand j'essaie d'eviter « linker », ce qui ne
m'arrive pas tres souvent.

Il y a aussi le problème que dans certains environnements
le "binding" c'est bien autre chose que le "linking" :-(
Et pour traduire différemment les deux en Français,
ça paraît difficile...

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France

kanze

07/06/2004 à 17:55

Jean-Marc Bourguet wrote in message
news:...

(En ce qui concerne la terminologie, je prefere les "shared object" de
Unix aux "DLL" de Windows car ca ne se comporte absolument pas comme
les autres bibliotheques du point de vue traite dans la discussion.)

Sauf que l'intérêt aujourd'hui, c'est bien l'aspect dynamique de
l'édition de liens, et non le fait qu'ils soit partagés.

J'ai une vague souvenir d'une discussion dans le comité C (il me
semble, et qui n'a en tout cas abouti à rien) -- à la fin, ils étaient
d'accord qu'il s'agissait des objets (et non des bibliothèques), mais
que le seul aspect qui intéressait la normalisation était bien l'aspect
dynamique. Alors, ils avaient choisi l'expression « dynamic object ». Ce
qui m'a semblé assez bien pour que je l'adopte moi-même.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Loïc Joly

07/06/2004 à 21:37

wrote:

D'abord, la norme n'en est pas entièrement silencieuse. Mais plus
généralement, ça fait partie de la définition de « objet » et de
«@bibliothèque ». Une bibliothèque, c'est une collection d'objets d'où
l'éditeur de liens tirent les objets nécessaires, et que les objets
nécessaires.

Avec la définition de nécessaire qui va bien.

Je m'étonne un peu que tu aies un problème ici. Si c'était quelqu'un
d'autre, je dirais que ça fait partie du b a ba de la compilation, et
qu'il aurait dû l'apprendre dans le premier cour du langage. Or, je sais
que tu as largement dépassé ce niveau.

Comme tu t'en doutes, je n'ai pas tant de problèmes que ça avec ce mode
de fonctionnement. Mon principal problème est qu'il ne me semble pas
décrit complètement décrit dans la norme, et que pour un débutant, il ne
coule pas forcément de source (une alternative pas forcément débile existe).

De plus, comme cette question ne se pose que dans les langages où la
construction d'une variable globale peut provoquer des effets
secondaires (et peut-être les langages dynamiques, je ne connais pas
assez le sujet), je ne suis pas certain que ce choix soit si ancien et
universellement reconnu que ça.

A l'heure où l'on parle de spécifier le fonctionnement des bibliothèques
dynamiques, avoir une spécification claire et complète des bibliothèques
statiques me semble un préalable nécessaire.

--
Loïc

kanze

08/06/2004 à 10:26

Loïc Joly wrote in message
news:<ca2ftt$4lc$...

wrote:

Je m'étonne un peu que tu aies un problème ici. Si c'était quelqu'un
d'autre, je dirais que ça fait partie du b a ba de la compilation,
et qu'il aurait dû l'apprendre dans le premier cour du langage. Or,
je sais que tu as largement dépassé ce niveau.

Comme tu t'en doutes, je n'ai pas tant de problèmes que ça avec ce
mode de fonctionnement. Mon principal problème est qu'il ne me semble
pas décrit complètement décrit dans la norme, et que pour un débutant,
il ne coule pas forcément de source (une alternative pas forcément
débile existe).

Ce sont, à mon avis, deux points complètement indépendants. Ce n'est pas
en lisant la norme qu'un débuttant va comprendre la récherche de nom
dans un template non plus.

En ce qui concerne la norme, je crois que l'absence d'une déscription
détaillée est intentionnelle. La norme ne dit rien sur comment invoquer
le compilateur, enchaîner une édition de liens, créer sa propre
bibliothèque, etc. C'est une décision exprès. On peut ne pas être
d'accord : quand je fais un « programme » en C++, ça comporte non
seulement des sources C++, mais aussi des fichiers make, etc. Et c'est
sûr, ça pose des problèmes de portabilité. Pourquoi pas s'y adresser ?
Mais c'est comme ça. Il y a des arguments des deux côtés, et dans
l'ensemble, je crois que c'est la bonne décision.

Or, ce qui concerne la façon qu'une implémentation traite une
bibliothèque, ça fait bien partie de ces aspects de commande du
compilateur. Comme j'ai déjà dit, je connais au moins trois variants ;
incorporer tous les objets dans la bibliothèque, sans poser une
question, en serait un quatrième. Un mauvais, à mon avis, qui poserait
tellement de problèmes que l'implémentation ne serait pas utilisable.
Mais ça serait probablement conforme.

En ce qui concerne le problème des débuttants, c'est toute une autre
histoire. Il y a certains principes de bases en ce qui concerne le
fonctionnement d'une bibliothèque, qui sont à peu près universel, et
dont la connaissance fait partie du b a ba de l'informatique. S'il y a
un problème ici, c'est que l'éducation du débuttant a sauté des étapes.
On ne peut pas savoir programmer en C++ sans savoir programmer tout
court. Et l'utilisation des bibliothèques, ça fait partie de savoir
programmer. Tout court.

De plus, comme cette question ne se pose que dans les langages où la
construction d'une variable globale peut provoquer des effets
secondaires (et peut-être les langages dynamiques, je ne connais pas
assez le sujet), je ne suis pas certain que ce choix soit si ancien et
universellement reconnu que ça.

Disons que dans la mésure où le C++ a choisi de se baser sur des
éditeurs de liens existants, le fonctionnement des bibliothèques est
plus ou moins donné. Le choix a été fait bien avant que je commence
l'informatique.

Refléchis-y un moment. Le but d'une bibliothèque, c'est bien d'offrir un
ensemble de services au programmeur. Non de lui en imposer toutes, dès
qu'il veut s'en servir d'une. À mon avis, le problème se présente pour
deux raisons :

- On se sert trop souvent du mauvais outil. Si on veut qu'un objet
fasse partir du programme, la solution correcte, c'est de dire à
l'éditeur de liens que cet objet doit faire partir du programme, non
de le mettre dans une bibliothèque avec l'espoir que l'éditeur de
liens va l'y trouver et l'incorporer. On abuse des bibliothèques
aujourd'hui ; normalement, les objets qui sont propres à ton
application n'ont aucune raison de se trouver dans une bibliothèque,
dont le but est de rendre disponible un ensemble de services
indépendantes. Si on veut que tous les objets dans une bibliothèque
fasse partie du programme, alors, la bibliothèque n'est pas l'outil
qui convient.

C'est une anomalie qui vient de Unix, je crois. Avant de faire Unix,
tous les éditeurs de liens que je connaissais prenaient un fichier
de commande, où je précisais tous les objets, bibliothèques,
commandes spéciales, etc. Or, sous Unix, il n'y a pas de fichier de
commande ; il faut préciser tout sur la ligne de commande. Une ligne
de commande dont la longueur est fort limitée. Alors, on est amené à
mettre les objets dans des bibliothèques simplement pour raccorcir
la ligne de commande -- ça fait moins de noms de fichier à donner.
Alors, sous Unix, moi aussi, je me sers des bibliothèques aussi
quand je sais que c'est un abus. Mais Windows n'a pas ce défaut, ou
au moins, l'éditeur de liens de VC++ ne l'a pas. Si je développais
uniquement sous Windows, je me servirais des bibliothèques que quand
je voulais une bibliothèque, et non pour contourner les idioties du
système.

- Sous Windows, Microsoft a décidé à appeler leurs objets dynamiques
« Dynamically Linked *Libraries* ». Des bibliothèques, donc, bien
qu'elles ne se comportent pas du tout comme une bibliothèque, encore
moins même que les « shared objects » sous Unix. Pour bien des gens,
une bibliothèque, c'est une DLL. Et ils acquierent une idée
complètement fausse sur ce que c'est qu'une bibliothèque, et à quoi
elle doit servir.

A l'heure où l'on parle de spécifier le fonctionnement des
bibliothèques dynamiques, avoir une spécification claire et complète
des bibliothèques statiques me semble un préalable nécessaire.

Pour l'instant, il n'est pas question de spécifier des bibliothèques
dynamiques. Si tu régardes bien, il y a discussion en ce qui concerne
un nouveau système de modularisation, qui comporte (fort probablement)
la possibilité de différer une partie de l'édition de liens jusqu'à
l'execution, avec même une édition de liens sous commande de
l'exécution. Ça n'a rien à voir avec des bibliothèques au sens
classique, et c'est dommage que les auteurs de la proposition ont
perpetré l'abus de langage de Microsoft dans le titre de leur
proprosition. En fait, dans la mésure où ils sont en train d'introduire
de (bonnes) restrictions sur la visibilité, etc., un meilleur nom serait
« dynamically linked modules ». Et tu as bien raison de dire qu'il
serait souhaitable qu'on définisse bien ce qu'on entend par module,
voire même définir le concepte des modules y compris pour des modules
linkées statiquement, avant de s'attaquer aux problèmes propre à
l'édition de liens dynamique.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<ca2ftt$4lc$1@news-reader5.wanadoo.fr>...

kanze@gabi-soft.fr wrote:

Je m'étonne un peu que tu aies un problème ici. Si c'était quelqu'un
d'autre, je dirais que ça fait partie du b a ba de la compilation,
et qu'il aurait dû l'apprendre dans le premier cour du langage. Or,
je sais que tu as largement dépassé ce niveau.

Comme tu t'en doutes, je n'ai pas tant de problèmes que ça avec ce
mode de fonctionnement. Mon principal problème est qu'il ne me semble
pas décrit complètement décrit dans la norme, et que pour un débutant,
il ne coule pas forcément de source (une alternative pas forcément
débile existe).

Ce sont, à mon avis, deux points complètement indépendants. Ce n'est pas
en lisant la norme qu'un débuttant va comprendre la récherche de nom
dans un template non plus.

En ce qui concerne la norme, je crois que l'absence d'une déscription
détaillée est intentionnelle. La norme ne dit rien sur comment invoquer
le compilateur, enchaîner une édition de liens, créer sa propre
bibliothèque, etc. C'est une décision exprès. On peut ne pas être
d'accord : quand je fais un « programme » en C++, ça comporte non
seulement des sources C++, mais aussi des fichiers make, etc. Et c'est
sûr, ça pose des problèmes de portabilité. Pourquoi pas s'y adresser ?
Mais c'est comme ça. Il y a des arguments des deux côtés, et dans
l'ensemble, je crois que c'est la bonne décision.

Or, ce qui concerne la façon qu'une implémentation traite une
bibliothèque, ça fait bien partie de ces aspects de commande du
compilateur. Comme j'ai déjà dit, je connais au moins trois variants ;
incorporer tous les objets dans la bibliothèque, sans poser une
question, en serait un quatrième. Un mauvais, à mon avis, qui poserait
tellement de problèmes que l'implémentation ne serait pas utilisable.
Mais ça serait probablement conforme.

En ce qui concerne le problème des débuttants, c'est toute une autre
histoire. Il y a certains principes de bases en ce qui concerne le
fonctionnement d'une bibliothèque, qui sont à peu près universel, et
dont la connaissance fait partie du b a ba de l'informatique. S'il y a
un problème ici, c'est que l'éducation du débuttant a sauté des étapes.
On ne peut pas savoir programmer en C++ sans savoir programmer tout
court. Et l'utilisation des bibliothèques, ça fait partie de savoir
programmer. Tout court.

De plus, comme cette question ne se pose que dans les langages où la
construction d'une variable globale peut provoquer des effets
secondaires (et peut-être les langages dynamiques, je ne connais pas
assez le sujet), je ne suis pas certain que ce choix soit si ancien et
universellement reconnu que ça.

Disons que dans la mésure où le C++ a choisi de se baser sur des
éditeurs de liens existants, le fonctionnement des bibliothèques est
plus ou moins donné. Le choix a été fait bien avant que je commence
l'informatique.

Refléchis-y un moment. Le but d'une bibliothèque, c'est bien d'offrir un
ensemble de services au programmeur. Non de lui en imposer toutes, dès
qu'il veut s'en servir d'une. À mon avis, le problème se présente pour
deux raisons :

- On se sert trop souvent du mauvais outil. Si on veut qu'un objet
fasse partir du programme, la solution correcte, c'est de dire à
l'éditeur de liens que cet objet doit faire partir du programme, non
de le mettre dans une bibliothèque avec l'espoir que l'éditeur de
liens va l'y trouver et l'incorporer. On abuse des bibliothèques
aujourd'hui ; normalement, les objets qui sont propres à ton
application n'ont aucune raison de se trouver dans une bibliothèque,
dont le but est de rendre disponible un ensemble de services
indépendantes. Si on veut que tous les objets dans une bibliothèque
fasse partie du programme, alors, la bibliothèque n'est pas l'outil
qui convient.

C'est une anomalie qui vient de Unix, je crois. Avant de faire Unix,
tous les éditeurs de liens que je connaissais prenaient un fichier
de commande, où je précisais tous les objets, bibliothèques,
commandes spéciales, etc. Or, sous Unix, il n'y a pas de fichier de
commande ; il faut préciser tout sur la ligne de commande. Une ligne
de commande dont la longueur est fort limitée. Alors, on est amené à
mettre les objets dans des bibliothèques simplement pour raccorcir
la ligne de commande -- ça fait moins de noms de fichier à donner.
Alors, sous Unix, moi aussi, je me sers des bibliothèques aussi
quand je sais que c'est un abus. Mais Windows n'a pas ce défaut, ou
au moins, l'éditeur de liens de VC++ ne l'a pas. Si je développais
uniquement sous Windows, je me servirais des bibliothèques que quand
je voulais une bibliothèque, et non pour contourner les idioties du
système.

- Sous Windows, Microsoft a décidé à appeler leurs objets dynamiques
« Dynamically Linked *Libraries* ». Des bibliothèques, donc, bien
qu'elles ne se comportent pas du tout comme une bibliothèque, encore
moins même que les « shared objects » sous Unix. Pour bien des gens,
une bibliothèque, c'est une DLL. Et ils acquierent une idée
complètement fausse sur ce que c'est qu'une bibliothèque, et à quoi
elle doit servir.

A l'heure où l'on parle de spécifier le fonctionnement des
bibliothèques dynamiques, avoir une spécification claire et complète
des bibliothèques statiques me semble un préalable nécessaire.

Pour l'instant, il n'est pas question de spécifier des bibliothèques
dynamiques. Si tu régardes bien, il y a discussion en ce qui concerne
un nouveau système de modularisation, qui comporte (fort probablement)
la possibilité de différer une partie de l'édition de liens jusqu'à
l'execution, avec même une édition de liens sous commande de
l'exécution. Ça n'a rien à voir avec des bibliothèques au sens
classique, et c'est dommage que les auteurs de la proposition ont
perpetré l'abus de langage de Microsoft dans le titre de leur
proprosition. En fait, dans la mésure où ils sont en train d'introduire
de (bonnes) restrictions sur la visibilité, etc., un meilleur nom serait
« dynamically linked modules ». Et tu as bien raison de dire qu'il
serait souhaitable qu'on définisse bien ce qu'on entend par module,
voire même définir le concepte des modules y compris pour des modules
linkées statiquement, avant de s'attaquer aux problèmes propre à
l'édition de liens dynamique.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Loïc Joly wrote in message
news:<ca2ftt$4lc$...

wrote:

Je m'étonne un peu que tu aies un problème ici. Si c'était quelqu'un
d'autre, je dirais que ça fait partie du b a ba de la compilation,
et qu'il aurait dû l'apprendre dans le premier cour du langage. Or,
je sais que tu as largement dépassé ce niveau.

Comme tu t'en doutes, je n'ai pas tant de problèmes que ça avec ce
mode de fonctionnement. Mon principal problème est qu'il ne me semble
pas décrit complètement décrit dans la norme, et que pour un débutant,
il ne coule pas forcément de source (une alternative pas forcément
débile existe).

Ce sont, à mon avis, deux points complètement indépendants. Ce n'est pas
en lisant la norme qu'un débuttant va comprendre la récherche de nom
dans un template non plus.

En ce qui concerne la norme, je crois que l'absence d'une déscription
détaillée est intentionnelle. La norme ne dit rien sur comment invoquer
le compilateur, enchaîner une édition de liens, créer sa propre
bibliothèque, etc. C'est une décision exprès. On peut ne pas être
d'accord : quand je fais un « programme » en C++, ça comporte non
seulement des sources C++, mais aussi des fichiers make, etc. Et c'est
sûr, ça pose des problèmes de portabilité. Pourquoi pas s'y adresser ?
Mais c'est comme ça. Il y a des arguments des deux côtés, et dans
l'ensemble, je crois que c'est la bonne décision.

Or, ce qui concerne la façon qu'une implémentation traite une
bibliothèque, ça fait bien partie de ces aspects de commande du
compilateur. Comme j'ai déjà dit, je connais au moins trois variants ;
incorporer tous les objets dans la bibliothèque, sans poser une
question, en serait un quatrième. Un mauvais, à mon avis, qui poserait
tellement de problèmes que l'implémentation ne serait pas utilisable.
Mais ça serait probablement conforme.

En ce qui concerne le problème des débuttants, c'est toute une autre
histoire. Il y a certains principes de bases en ce qui concerne le
fonctionnement d'une bibliothèque, qui sont à peu près universel, et
dont la connaissance fait partie du b a ba de l'informatique. S'il y a
un problème ici, c'est que l'éducation du débuttant a sauté des étapes.
On ne peut pas savoir programmer en C++ sans savoir programmer tout
court. Et l'utilisation des bibliothèques, ça fait partie de savoir
programmer. Tout court.

De plus, comme cette question ne se pose que dans les langages où la
construction d'une variable globale peut provoquer des effets
secondaires (et peut-être les langages dynamiques, je ne connais pas
assez le sujet), je ne suis pas certain que ce choix soit si ancien et
universellement reconnu que ça.

Disons que dans la mésure où le C++ a choisi de se baser sur des
éditeurs de liens existants, le fonctionnement des bibliothèques est
plus ou moins donné. Le choix a été fait bien avant que je commence
l'informatique.

Refléchis-y un moment. Le but d'une bibliothèque, c'est bien d'offrir un
ensemble de services au programmeur. Non de lui en imposer toutes, dès
qu'il veut s'en servir d'une. À mon avis, le problème se présente pour
deux raisons :

- On se sert trop souvent du mauvais outil. Si on veut qu'un objet
fasse partir du programme, la solution correcte, c'est de dire à
l'éditeur de liens que cet objet doit faire partir du programme, non
de le mettre dans une bibliothèque avec l'espoir que l'éditeur de
liens va l'y trouver et l'incorporer. On abuse des bibliothèques
aujourd'hui ; normalement, les objets qui sont propres à ton
application n'ont aucune raison de se trouver dans une bibliothèque,
dont le but est de rendre disponible un ensemble de services
indépendantes. Si on veut que tous les objets dans une bibliothèque
fasse partie du programme, alors, la bibliothèque n'est pas l'outil
qui convient.

C'est une anomalie qui vient de Unix, je crois. Avant de faire Unix,
tous les éditeurs de liens que je connaissais prenaient un fichier
de commande, où je précisais tous les objets, bibliothèques,
commandes spéciales, etc. Or, sous Unix, il n'y a pas de fichier de
commande ; il faut préciser tout sur la ligne de commande. Une ligne
de commande dont la longueur est fort limitée. Alors, on est amené à
mettre les objets dans des bibliothèques simplement pour raccorcir
la ligne de commande -- ça fait moins de noms de fichier à donner.
Alors, sous Unix, moi aussi, je me sers des bibliothèques aussi
quand je sais que c'est un abus. Mais Windows n'a pas ce défaut, ou
au moins, l'éditeur de liens de VC++ ne l'a pas. Si je développais
uniquement sous Windows, je me servirais des bibliothèques que quand
je voulais une bibliothèque, et non pour contourner les idioties du
système.

- Sous Windows, Microsoft a décidé à appeler leurs objets dynamiques
« Dynamically Linked *Libraries* ». Des bibliothèques, donc, bien
qu'elles ne se comportent pas du tout comme une bibliothèque, encore
moins même que les « shared objects » sous Unix. Pour bien des gens,
une bibliothèque, c'est une DLL. Et ils acquierent une idée
complètement fausse sur ce que c'est qu'une bibliothèque, et à quoi
elle doit servir.

A l'heure où l'on parle de spécifier le fonctionnement des
bibliothèques dynamiques, avoir une spécification claire et complète
des bibliothèques statiques me semble un préalable nécessaire.

Pour l'instant, il n'est pas question de spécifier des bibliothèques
dynamiques. Si tu régardes bien, il y a discussion en ce qui concerne
un nouveau système de modularisation, qui comporte (fort probablement)
la possibilité de différer une partie de l'édition de liens jusqu'à
l'execution, avec même une édition de liens sous commande de
l'exécution. Ça n'a rien à voir avec des bibliothèques au sens
classique, et c'est dommage que les auteurs de la proposition ont
perpetré l'abus de langage de Microsoft dans le titre de leur
proprosition. En fait, dans la mésure où ils sont en train d'introduire
de (bonnes) restrictions sur la visibilité, etc., un meilleur nom serait
« dynamically linked modules ». Et tu as bien raison de dire qu'il
serait souhaitable qu'on définisse bien ce qu'on entend par module,
voire même définir le concepte des modules y compris pour des modules
linkées statiquement, avant de s'attaquer aux problèmes propre à
l'édition de liens dynamique.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Michel Michaud

09/06/2004 à 05:02

Dans news:,

"Michel Michaud" wrote in message
news:<C82wc.120883$...

Peut-être le mieux alors, c'est « linker ». Au moins comme
ça, on est sûr que tout le monde nous comprend:-).

Non, le mieux est « éditeur de liens ». Comme ça, on parle
français et on utilise la bonne traduction...

Et « faire une édition de liens », ou « éditer des liens »,
plutôt que « linker » ?

Oui, faire l'édition des liens.

Je suis d'accord pour parler français, mais ça devient un peu
lourd à la longue, tu ne trouves pas ?

Je ne vois pas pourquoi. Si je trouvais que parler français
était lourd, je m'arrangerais pour parler une autre langue :-)

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Michel Michaud

09/06/2004 à 05:04

Dans news:40c43b25$0$21563$, Alain

"Jean-Marc Bourguet" a écrit dans le message
news:
writes:

"Michel Michaud" wrote in message
news:<C82wc.120883$...

Peut-être le mieux alors, c'est « linker ». Au moins comme
ça, on est sûr que tout le monde nous comprend:-).

Non, le mieux est « éditeur de liens ». Comme ça, on parle
français et on utilise la bonne traduction...

Et « faire une édition de liens », ou « éditer des liens »,
plutôt que « linker » ?

J'utilise « lier » quand j'essaie d'eviter « linker », ce qui
ne m'arrive pas tres souvent.

Il y a aussi le problème que dans certains environnements
le "binding" c'est bien autre chose que le "linking" :-(
Et pour traduire différemment les deux en Français,
ça paraît difficile...

L'éditeur de liens fait l'édition des liens. C'est clair et
simple. « Binding » peut alors se traduire par lié (ou relié)
il me semble, ou reliure si on ne veut pas le verbe, et pas
seulement en informatique.

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Gabriel Dos Reis

09/06/2004 à 16:43

Loïc Joly writes:

| wrote:
|
|
| > D'abord, la norme n'en est pas entièrement silencieuse. Mais plus
| > généralement, ça fait partie de la définition de « objet » et de
| > «@bibliothèque ». Une bibliothèque, c'est une collection d'objets d'où
| > l'éditeur de liens tirent les objets nécessaires, et que les objets
| > nécessaires.
|
| Avec la définition de nécessaire qui va bien.

James a raison.

Traditionnellement, les bibliothèques sont des archives de fichiers
« objets » (.o). Le lieu en général y pique ce dont il a besoin.
En particulier s'il n'a pas besoin de ton MonObjet, il n'y a pas de
raison pour qu'il le prenne. Par exemple, quand tu lis ton programme
contre libX11.a (par exemple), tu n'as pas particulèrement envie que
le linker dumpe litéralement tout libX11.a dans ton programme. Plutôt,
tu as envoie qu'il y pique les définitions nécesaires.

Cela est radicalement différent de quand tu spécifies explicitement au
compilateur la liste des fichiers « objets » qui composent ton programme.

[...]

| A l'heure où l'on parle de spécifier le fonctionnement des
| bibliothèques dynamiques, avoir une spécification claire et complète
| des bibliothèques statiques me semble un préalable nécessaire.

Mais je n'ai pas vu où tu as montré que c'était un préalable et que
c'était nécessaire.

-- Gaby

Gabriel Dos Reis

09/06/2004 à 16:50

writes:

| En ce qui concerne la norme, je crois que l'absence d'une déscription
| détaillée est intentionnelle.

Absolument.

[...]

| > A l'heure où l'on parle de spécifier le fonctionnement des
| > bibliothèques dynamiques, avoir une spécification claire et complète
| > des bibliothèques statiques me semble un préalable nécessaire.
|
| Pour l'instant, il n'est pas question de spécifier des bibliothèques
| dynamiques. Si tu régardes bien, il y a discussion en ce qui concerne
| un nouveau système de modularisation, qui comporte (fort probablement)
| la possibilité de différer une partie de l'édition de liens jusqu'à
| l'execution, avec même une édition de liens sous commande de
| l'exécution. Ça n'a rien à voir avec des bibliothèques au sens
| classique, et c'est dommage que les auteurs de la proposition ont
| perpetré l'abus de langage de Microsoft dans le titre de leur
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| proprosition.

Si je voulais être mauvaise langue, je dirais que tu connais le nom de
l'auteur :-) :-)

| En fait, dans la mésure où ils sont en train d'introduire
| de (bonnes) restrictions sur la visibilité, etc., un meilleur nom serait
| « dynamically linked modules ». Et tu as bien raison de dire qu'il

Dans les discussions sur le réflecteur, il y a plus d'un an, quelqu'un
(Fergus Henderson je crois) avait suggéré « load units » -- je crois
que cela avait plu à l'époque.

| serait souhaitable qu'on définisse bien ce qu'on entend par module,

Je crois que plusieurs personnes ont leurs propres idées sur ce qu'est
un module ou ce que serait un module en C++. Personnellement, je
trouverais inapproprié de l'utiliser ici.

| voire même définir le concepte des modules y compris pour des modules
| linkées statiquement, avant de s'attaquer aux problèmes propre à
| l'édition de liens dynamique.

-- Gaby

Gabriel Dos Reis

09/06/2004 à 16:52

Loïc Joly writes:

| Jean-Marc Bourguet wrote:
|
| > Loïc Joly writes:
| >
| >>A moins que ce soit ma lecture du standardese qui soit déficiente,
| >>"Library components are linked to satisfy external references to
| >>functions and objects not defined in the current translation." me
| >>semble un peu vague.
| > J'ai toujours compris ce "Library" comme faisant reference a la
| > bibliotheque standard.

Moi aussi.

| Tiens, intéressant. Si c'est le cas, le concept de bibliothèque
| utilisateur n'est plus seulement très vaguement défini par la norme,
| mais il lui est totalement étranger.

Tout comme compilateur ou invocation du compilateur.

-- Gaby

Question sur la compilation

10 réponses

Veuillez sélectionner un problème