Utilité DLL C++

Vincent Burel wrote:

"kanze" <kanze@gabi-soft.fr> wrote in message
news:1157990351.992408.103510@e3g2000cwe.googlegroups.com...
Arnold McDonald (AMcD) wrote:
> Alain Gaillard wrote:

> > > Tiens au fait toi qui parle volontiers "d'engueulo, de franche
> > > camaraderie, de docte". Que dirais tu toi même de ta propre
> > > intervention là ? LOL

> > Je connais la plupart des intervenants ici depuis des années.
> > Eux aussi...

> Attention ! Il y a un cross-posting. Je suis un reguilier de
>fr.comp.lang.c++, où je lis ces postings, et je ne t'y aie
>jamais vu.

>C'est d'ailleurs sans doute pour ça que Alain et moi ont tant de
>problèmes à se faire comprendre. S'il avait fréquenté
>fr.comp.lang.c++ avant, je suis assez sûr qu'il se serait rendu
>compte que ce n'était pas nécessaire à m'expliquer la mémoire
>virtuelle, et qu'il devait avoir quelque chose d'autre derrière
>ma question. (Et que n'étant pas francophone d'origine, j'ai
>parfois du mal à m'exprimer bien comme il faut.)

Sans vouloir polémiquer, je pense qu'il faut toujours avoir la
bienveillance d'expliquer ce qui touche au processeur en
particulier et à la machine en générale, à qqn qui vient de
fr.comp.lang.c/c++ ...

Ça dépend de la contexte. Si Alain avait fréquenté
fr.comp.lang.c++, il me connaîtrait, et il saurait que dans mon
cas, ce n'était pas nécessaire. (Ceci dit : est-ce qu'il est
réelement nécessaire à expliquer la mémoire virtuelle à qui que
ce soit. Ça fait partie du monde informatique depuis bien une
trentaine d'années, et j'ai du mal à concevoir qu'un ingenieur
en informatique n'en soit pas conscient. Qui n'a pas déjà vu des
problèmes de thrashing, par exemple ?)

l'Expérience montre qu'un certain nombre de choses leur
échappent quand il s'agit de parler d'informatique. D'ailleurs
si je me souviens bien, dans ce genre de newsgroup, on a pas
le droit de parler d'autre chose que du langage et de sa
norme.

En principe. Pas forcément la norme, mais on préfère
effectivement éviter des aspects trop particuliers à une
plate-forme. Mais comme tu vois, ça ne nous empèche pas de
parler du chargement dynamique, et comment il se fait. Parce que
même si le chargement dynamique ne fait pas partie de la norme
aujourd'hui, il est assez universellement disponible et utilisé
(et il y a des discussions de le traiter dans la prochaine
version de la norme).

Ça ne veut pas dire, évidemment, qu'on travaille dans le vide,
avec le langage seulement, sans jamais savoir ce que se passe en
dessus. Des discussions de localité, par exemple, sous entendent
bien une connaissance de la mémoire virtuelle, sans parler des
discussions parfois assez pointues sur la gestion des threads
(et ce qui est garantie en pratique, et ce qui ne l'est pas).

C'est pourquoi certains ici, comme moi, se sont permis de
faire des petits rappels pédagogiques sur le systeme windows,
et je me réjouis que cela fut inutile. j'en déduits qu'enfin
certains sont finalement devenus programmeurs... Bravo ! :-)

Ce qui m'agaçait un peu, c'est que j'avais parfois l'impression
qu'on présentait des choses comme quelque chose de propre à
Windows. Or que Windows (comme la majeur partie des systèmes
commerciaux, d'ailleurs) a fort peu innové ; prèsque tout ce
qu'on y trouve existait avant, en général depuis longtemps. (Je
sais que quand je dois faire quelque choses sous Windows, j'ai
l'impression de retourner dans le temps. Disons à l'époque de
Sun OS 3, 1990, environ. Mais c'est une impression qui vient de
son interface graphique, qui date vraiement : un seul plan de
travail, par exemple, alors que je m'en sers de plusieurs depuis
bien plus de quinze ans, où le fait de ne pas pouvoir avoir des
fenêtres ouvertes sur plusieurs machines à la fois, ou d'avoir
un programme qui gère des fenêtres sur plusieurs machines en
simultané.)

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

Jean-Marc Bourguet wrote:

[...]

Le problème est exactement le même on est à l'étroit dans
l'espace adressable disponible (20 bits avec un 8086, 32 bits
avec un x86), et on cherche à avoir plus de mémoire physique.
La solution est similaire: dans le premier cas, on a ajouté du
hard permettant de swapper une fenêtre. Dans le second cas,
on a étendu une partie du hard existant qui permettait déjà
d'avoir des fenêtres (on s'en était servi pour simuler la
mémoire LIM) pour que lui puisse adresser plus de 32 bits sans
que les applications aient à changer.

Au fait, cette technique est encore plus vieille...

Au départ, on le faisait manuellement, avec des zones de
« overlay ». Les éditeurs de liens de l'époque le supporter.
Je ne me mettrais pas la main au feu, mais je crois que cette
technique servait déjà sur des IBM 1401 (début des années 1960),
voire avant.

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

"kanze" <kanze@gabi-soft.fr> wrote in message
news:1158046159.850024.94650@i42g2000cwa.googlegroups.com...
Vincent Burel wrote:

"kanze" <kanze@gabi-soft.fr> wrote in message

Sans vouloir polémiquer, je pense qu'il faut toujours avoir la
bienveillance d'expliquer ce qui touche au processeur en
particulier et à la machine en générale, à qqn qui vient de
fr.comp.lang.c/c++ ...

Ça dépend de la contexte. Si Alain avait fréquenté
fr.comp.lang.c++, il me connaîtrait, et il saurait que dans mon
cas, ce n'était pas nécessaire. (Ceci dit : est-ce qu'il est
réelement nécessaire à expliquer la mémoire virtuelle à qui que
ce soit. Ça fait partie du monde informatique depuis bien une
trentaine d'années, et j'ai du mal à concevoir qu'un ingenieur
en informatique n'en soit pas conscient. Qui n'a pas déjà vu des
problèmes de thrashing, par exemple ?)

je vous taquine, mais franchement quand je vois les programmeurs C++ ne pas
faire la différence entre l'opérateur "new" (createur d'objet ++) et une
fonction d'allocation mémoire (généralement fournit par le système) , je me
dis que j'ai aucune raison de croire que les concepts de mémoire virtuelle
ou de mappage d'adresses logique et physique, ne leur passent pas au dessus
du bocal... D'ailleurs vous même, au début de ce thread-demi-troll, aviez
zappé le fait qu'une DLL était dynamiquement relogé dans l'espace
d'adressage de l'application au chargement...

[...]

Ce qui m'agaçait un peu, c'est que j'avais parfois l'impression
qu'on présentait des choses comme quelque chose de propre à
Windows. Or que Windows (comme la majeur partie des systèmes
commerciaux, d'ailleurs) a fort peu innové ;

Vous etes ici sur un forum relatif à windows. Et nous savons que Bill n'a
pas inventé grand chose, et il nous tardait dans les années 2000 qu'enfin il
mette un noyau unix-like dans son bouzin... De toute manière, quand on
regarde les spec des processeurs, les faiseurs d'OS n'ont pas trop le choix,
ils sont obligés de suivrent ... d'ailleurs fondamentalement il n'y plus
beaucoup de différence entre les O/S généralistes, ca se joue sur le
déploiment et le taux de controle (user ou supervisor)...

VB

kanze a écrit :

Attention ! Il y a un cross-posting.

Ah oui, je n'avais pas remarqué. Du coup je comprends moins mal un des
intervenants.

C'est d'ailleurs sans doute pour ça que Alain et moi ont tant de
problèmes à se faire comprendre. S'il avait fréquenté
fr.comp.lang.c++ avant,

En fait James, je fréquente assez régulièrement le groupe
fr.comp.lang.c++ depuis 1997 je crois. Je n'y interviens pas toujours
faute de temps, mais j'ai plaisir à lire régulièrement les posts.
C'est d'ailleurs pour moi l'occasion de dire que j'apprécie tous les
intervenants réguliers de ce groupe.

Je dois confesser que pour des raisons qui m'appartiennent, Alain
Gaillard n'est pas du tout mon vrai nom mais un pseudo chosi récemment.

je suis assez sûr qu'il se serait rendu
compte que ce n'était pas nécessaire à m'expliquer la mémoire
virtuelle,

Donc comme je te lis depuis fort longtemps, en effet je sais que tu sais
ce qu'est la mémoire virtuelle, et tes compétences ne sont aucunement en
cause, à aucun niveau.

et qu'il devait avoir quelque chose d'autre derrière
ma question. (Et que n'étant pas francophone d'origine, j'ai
parfois du mal à m'exprimer bien comme il faut.)

Tu t'exprimes suffisamment bien en français pour que je souhaite être
capable d'en faire autant en anglais.
Tu sais la discussion a suivi son cours rapidement, j'ai (j'ai essayé)
suivi tout en bossant, il est fort probable que nous ne nous soyons pas
compris, sans doute par ma faute.

--
Alain

"kanze" <kanze@gabi-soft.fr> writes:

Jean-Marc Bourguet wrote:

[...]

Le problème est exactement le même on est à l'étroit dans
l'espace adressable disponible (20 bits avec un 8086, 32 bits
avec un x86), et on cherche à avoir plus de mémoire physique.
La solution est similaire: dans le premier cas, on a ajouté du
hard permettant de swapper une fenêtre. Dans le second cas,
on a étendu une partie du hard existant qui permettait déjà
d'avoir des fenêtres (on s'en était servi pour simuler la
mémoire LIM) pour que lui puisse adresser plus de 32 bits sans
que les applications aient à changer.

Au fait, cette technique est encore plus vieille...

Au départ, on le faisait manuellement, avec des zones de
« overlay ». Les éditeurs de liens de l'époque le supporter.
Je ne me mettrais pas la main au feu, mais je crois que cette
technique servait déjà sur des IBM 1401 (début des années 1960),
voire avant.

Avant. Jean Sammet, dans Programming Languages, History and
Fundamentals, décrit Math-Matic, un langage développé en
1953 pour les Univacs I, faisait ce qu'elle appelle de la
segmentation automatique, et qui correspond à de la gestion
d'overlay sans aide du programmeur. Le système telle
qu'elle le décrit était suffisemment sophistiqué pour garder
les boucles dans le même overlay autant que possible
(Univac, c'est une machine avec 1000 mots de 12 caractères
de mémoire -- et 6 bits par caractères).

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

Vincent Burel wrote:

"kanze" <kanze@gabi-soft.fr> wrote in message
news:1158046159.850024.94650@i42g2000cwa.googlegroups.com...
Vincent Burel wrote:
> "kanze" <kanze@gabi-soft.fr> wrote in message
>> Sans vouloir polémiquer, je pense qu'il faut toujours avoir la
>> bienveillance d'expliquer ce qui touche au processeur en
>> particulier et à la machine en générale, à qqn qui vient de
>> fr.comp.lang.c/c++ ...

>Ça dépend de la contexte. Si Alain avait fréquenté
>fr.comp.lang.c++, il me connaîtrait, et il saurait que dans
>mon cas, ce n'était pas nécessaire. (Ceci dit : est-ce qu'il
>est réelement nécessaire à expliquer la mémoire virtuelle à
>qui que ce soit. Ça fait partie du monde informatique depuis
>bien une trentaine d'années, et j'ai du mal à concevoir qu'un
>ingenieur en informatique n'en soit pas conscient. Qui n'a
>pas déjà vu des problèmes de thrashing, par exemple ?)

je vous taquine, mais franchement quand je vois les
programmeurs C++ ne pas faire la différence entre l'opérateur
"new" (createur d'objet ++) et une fonction d'allocation
mémoire (généralement fournit par le système),

Mais quand on sait que l'opérateur s'appelle en anglais
« the operator new » et que le nom de la fonction est
« operator new() », on comprend qu'il peut y avoir de la
confusion pour quelqu'un qui n'est pas entré dans les détails.
Je sais que même à l'intérieur du comité de normalisation, il
faut faire attention comment on en parle pour éviter des
ambiguïtés.

je me dis que j'ai aucune raison de croire que les concepts de
mémoire virtuelle ou de mappage d'adresses logique et
physique, ne leur passent pas au dessus du bocal...

Je suis peut-être optimiste, mais je suppose que la plupart des
ingenieurs ont fait des études supérieur (même si je n'ai pas le
bac moi-même). Et j'imagine que des études supérieur
(universitaire ou grande école) comporte bien au moins une
présentation de l'architecture hardware, et que donc, on sait à
peu près ce que c'est la mémoire virtuelle, et même
l'organisation hiérarchisée de la mémoire (cache, etc.). (Qu'on
en reconnaît toutes les conséquences, c'est moins évident, et
j'ai l'habitude que des gens -- parfois même assez
compétents -- ne s'en rendent pas toujours compte des
implications dans un environement multi-thread.)

D'ailleurs vous même, au début de ce thread-demi-troll, aviez
zappé le fait qu'une DLL était dynamiquement relogé dans
l'espace d'adressage de l'application au chargement...

Et à la fin, il faut bien constater que j'avais raison:-).

Si j'ai réagi de la sorte, c'est précisement parce que je savais
ce que ça impliquait. C'est parce que j'ai déjà écrit du code
indépendant de la position (en 8086) que je connaissais les
problèmes que ça pose. (Que je n'ai pas su les exprimer
clairement, c'est un autre problème.)

[...]

>Ce qui m'agaçait un peu, c'est que j'avais parfois
>l'impression qu'on présentait des choses comme quelque chose
>de propre à Windows. Or que Windows (comme la majeur partie
>des systèmes commerciaux, d'ailleurs) a fort peu innové ;

Vous etes ici sur un forum relatif à windows. Et nous savons
que Bill n'a pas inventé grand chose, et il nous tardait dans
les années 2000 qu'enfin il mette un noyau unix-like dans son
bouzin...

C'est peut-être encore un problème de compréhension, mais
j'avais bien l'impression qu'on présentait la mémoire virtuelle
comme quelque chose de propre à Windows.

De toute manière, quand on regarde les spec des processeurs,
les faiseurs d'OS n'ont pas trop le choix, ils sont obligés de
suivrent ... d'ailleurs fondamentalement il n'y plus beaucoup
de différence entre les O/S généralistes, ca se joue sur le
déploiment et le taux de controle (user ou supervisor)...

Au fond, c'est vrai. Un faiseur d'OS n'est pas obligé à se
servir de la mémoire virtuelle sur Intel, ni même de la
protection. Mais s'il veut la mémoire virtuelle et la
protection (et j'ai du mal à imaginer un système généraliste
sans), il faut bien qu'il le fasse de la manière prévue par
Intel.

Sauf, évidemment, que s'il s'appelle Sun, et que l'hardware est
un processeur Sparc (comme c'est le cas où je travaille):-).
(Mais même alors, ce n'est que les détails qui changent.)

(Au fond, la façon qu'ils gèrent le chargement dynamique est une
des rares différences signifiantes entre Unix et Windows. Pas
pour ce qui nous concernait ici, mais en ce qui concerne la
visibilité des symboles, etc.)

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

"kanze" <kanze@gabi-soft.fr> wrote in message
news:1158133686.938577.99700@i3g2000cwc.googlegroups.com...
Vincent Burel wrote:

"kanze" <kanze@gabi-soft.fr> wrote in message
news:1158046159.850024.94650@i42g2000cwa.googlegroups.com...
Vincent Burel wrote:
> "kanze" <kanze@gabi-soft.fr> wrote in message

Je suis peut-être optimiste, mais je suppose que la plupart des
ingenieurs ont fait des études supérieur (même si je n'ai pas le
bac moi-même). Et j'imagine que des études supérieur
(universitaire ou grande école) comporte bien au moins une
présentation de l'architecture hardware, et que donc, on sait à
peu près ce que c'est la mémoire virtuelle.

Peut-etre en école d'ingé, mais à la fac, ca m'étonnerait qu'il rentre dans
le système, et encore moins dans le processor... je me rappelle en 90
(l'époque du C++/jave naissant) la mode c'était abstraction et encore
abstraction. Et puis dans la réalité, les gens qui programment sont pas
toujours des ingénieurs en informatique ! je dirais même "pas souvent".

Au fond, c'est vrai....

On arrive à tomber d'accord ! c'est formidable !
ou bien c'est qu'on vieilli. :-)

VB

Bonjour,

Peut-etre en école d'ingé, mais à la fac, ca m'étonnerait qu'il

Je dirais : meme en ecole d'inge ! Les IUT/IUP en font plus la
dessus !

rentre dans le système, et encore moins dans le processor... je me
rappelle en 90 (l'époque du C++/jave naissant) la mode c'était
abstraction et encore abstraction. Et puis dans la réalité, les gens
qui programment sont pas toujours des ingénieurs en informatique ! je
dirais même "pas souvent".

C'est vrai que maintenant, on fait presque que du java. Du coup,
le system, comment ca marche, on s'en cogne. Et après, les gens
se retrouve a faire du C++ ou autre (tout n'est pas java) et n'ont
pas lma culture systeme pour comprendre ce qu'il font...

D'ailleurs, meme pour faire du java, comprendre un minimum ce
qui se passe quand on fait les choses (pourquoi une boucle
vide tourne plus vite que la meme boucle qui fait un printf
ou un System.println), ben ca change pas mal la qualite
du code (en performance en tout cas...).

Doms.

Korchkidu wrote:

Bonjour,

A partir de quand estimez vous que faire une DLL plutot qu'un LIB soit
intéressant. En effet, utiliser des DLL fait des programmes plus
petits (entre autres) mais induit d'enormes contraintes au niveau de la
programmation. Donc d'apres moi, faire une DLL pour une bibliotheque de
petite taille n'est pas forcement une bonne idee...

Donc pour resumer les reponses, il apparait qu'il faut utiliser le
moins possible les DLL. Uniquement lorsque c'est obligatoire... Merci a
tous pour vos reponses, pas toujours intelligibles mais merci quand
meme...;)

K.

benoit.lecallennec@gmail.com :

Donc pour resumer les reponses, il apparait qu'il faut utiliser le
moins possible les DLL. Uniquement lorsque c'est obligatoire...

C'est peut-être un peu raccourci, comme conclusion. A mon sens, il faut
utiliser les DLL principalement - je dis bien *PRINCIPALEMENT* - lorsque
1- du code est partagé entre plusieurs programmes pour éviter
d'encombrer la mémoire, ou 2- quand on veut faire des mises à jour
partielles, avec quelques précautions de compatibilité dans ce cas, ou
encore 3- quand un programme a besoin d'un module parmi plusieurs
existants qui font la même chose vu du programme mais la font de façon
différente pour chaque DLL ou dans des environnements différents.

Ma conclusion personnelle, c'est que 1- les mémoires actuelles sont
vastes et qu'en dehors de quelques mammouths, les redondances de code en
mémoire et sur disque ne sont pas un drame sauf pour quelques
fondamentalistes monomaniaques de l'optimisation, et que 2- les supports
de stockage et les vitesses de téléchargement actuelles font que,
toujours en dehors des mammouths, les utilisateurs ne voient pas tous la
différence entre la mise à jour d'une partie du code DLL ou du programme
complet.

Le point 3 me semble a contrario le plus intéressant. Je prends mon cas
personnel : je pilote avec différents modules d'un logiciel unique des
machines-outils qui ont des protocoles de communication et des langages
de commande complètement différents. Pour autant les fonctions vues des
composants du logiciel sont toutes identiques. Dans ce cas, une DLL
spécifique pour chaque type de machine devient intéressant, d'abord
parce que ça évite de charger en mémoire le code pour toutes les
machines alors qu'une seule est pilotée, ensuite parce que ça évite
qu'une modif du code dans la DLL associée à la machine X ne vienne
perturber le pilotage de celle de la machine Y, enfin parce que le code
est plus standard et donc plus lisible et facile à maintenir. Dans ce
dernier cas, donc, la différence entre une DLL et un driver de
périphérique (par exemple d'imprimante) est qu'on fournit plusieurs
DLL's dont une seule sera finalement utilisée, et ne sera utilisée que
par l'application qu'on fournit. Donc pas besoin de descendre d'un
niveau dans le système.

En post-scriptum, j'ajouterai que si tu ne vois pas un avantage immédiat
à organiser ton programme avec des DLL, alors ne te complique pas
l'existence en les utilisant. Ce qui rejoint ta propre conclusion.
T'avais donc raccourci mais quand même bon.