Discussion :

[astrotouf]

salut à tous ! voila ma question: lorsque l'on met dans notre programme

Code :

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

#include <stdio.h>

par exemple. et que l'on utilise une fonction dans cette librairie printf par exemple.
lorsque l'édition de liens commence. est ce que tout le code de la librairie est mis dans l'exécutable ou est ce juste le code de la fonction qui est recopié ?

[hegros]

Normalement à chaque appel de printf dans ton code on le remplace par son code binaire, soit autant de recopie que tu fais d'appel.

[Médinoc]

Bonjour,

1. Je rappelle que stdio.h est un fichier d'en-tête. Un fichier d'en-tête de la bibliothèque standard du C.
2. Pour répondre à ta question, seule la fonction printf() et toutes les fonctions utilisées en interne par printf() seront copiées dans l'exécutable.
   Et encore, seulement si l'exécutable est lié statiquement à la bibliothèque standard. Si l'exécutable est lié dynamiquement à la bibliothèque standard, aucune fonction ne sera recopiée et toute la bibliothèque sera dans une DLL.

hegros: Moult te goures. Tu sembles supposer que toutes les fonctions sont inline.

[hegros]

Je ne suppose rien du tout. C'est ce qui est fait lorsque la liaison est statique

[astrotouf]

donc je récapitule la directive préprocesseur #include est remplacée dans le fichier .c par tous les prototypes de fonctions qu'il y dedans (pour la verification du compilateur). Ensuite, l'editeur de lien prend seulement le fichier binaire des fonctions utilisées dans mon code source et les inclus dans mon exécutable c'est tout.
j'ai bien compris ou pas?

[Médinoc]

Je ne suppose rien du tout. C'est ce qui est fait lorsque la liaison est statique

Ben non: On ne recopie qu'une fois printf() dans le code exécutable, et chaque appel n'est rien de plus qu'un appel.

[Médinoc]

donc je récapitule la directive préprocesseur #include est remplacée dans le fichier .c par tous les prototypes de fonctions qu'il y dedans (pour la verification du compilateur). Ensuite, l'editeur de lien prend seulement le fichier binaire des fonctions utilisées dans mon code source et les inclus dans mon exécutable c'est tout.
j'ai bien compris ou pas?

Je dirais que oui.

[Jean-Marc.Bourguet]

Je ne suppose rien du tout. C'est ce qui est fait lorsque la liaison est statique

Et quand la fonction est recursive, que se passe-t'il?

[Jean-Marc.Bourguet]

salut à tous ! voila ma question: lorsque l'on met dans notre programme

Code :

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

#include <stdio.h>

par exemple. et que l'on utilise une fonction dans cette librairie printf par exemple.
lorsque l'édition de liens commence. est ce que tout le code de la librairie est mis dans l'exécutable ou est ce juste le code de la fonction qui est recopié ?

Si on lie statiquement la bibliotheque standard (ce qui est rarissime de nos jours sous Unix, je ne connais rien a Windows), tu ne recuperes que ce qui est potentiellement necessaire. Potentiellement parce que suivant l'unite avec laquelle travaille l'editeur de liens, tu peux recuperer plus: la norme sous Unix etait de lier fichier source par fichier source; au moins la paire gcc/gld permet de faire plus fin avec les options adequates (-ffunction-section ou quelque chose du genre).

Si on lie dynamiquement, naturellement l'executable ne contient rien du tout de la bibliotheque, mais celle-ci sera chargee completement a l'execution.

(Excuse-moi si je me trompe, mais il me semble de plus que tu confonds entete et bibliotheque; la difference a largement ete commentee ici dans le passe).

Edit: je ne fais que dire autrement ce qu'a deja ecrit Medinoc, je me demande comment j'ai lu le fil.

[astrotouf]

Si on lie statiquement la bibliotheque standard (ce qui est rarissime de nos jours sous Unix, je ne connais rien a Windows), tu ne recuperes que ce qui est potentiellement necessaire. Potentiellement parce que suivant l'unite avec laquelle travaille l'editeur de liens, tu peux recuperer plus: la norme sous Unix etait de lier fichier source par fichier source; au moins la paire gcc/gld permet de faire plus fin avec les options adequates (-ffunction-section ou quelque chose du genre).

Si on lie dynamiquement, naturellement l'executable ne contient rien du tout de la bibliotheque, mais celle-ci sera chargee completement a l'execution.

(Excuse-moi si je me trompe, mais il me semble de plus que tu confonds entete et bibliotheque; la difference a largement ete commentee ici dans le passe).

Edit: je ne fais que dire autrement ce qu'a deja ecrit Medinoc, je me demande comment j'ai lu le fil.

ça c'est une trés bonne réponse !!
bon alors je vais en revenir à ce dont j'ai besoin réellement. lorsqu'on utilise une bibliothèque comme GTK+, je pense que dans ce cas on l'utilise de manière dynamique puisqu'il faut un runtime pour faire marcher les programmes GTK+ ?
est-ce-que les librairies utilisées par la bibliothéque sont totalement chargées en mémoire (libg, pango ...etc) ou est ce qu'elle ne charge que les choses les plus nécessaires (les fonctions appelées dans notre code source?
voyez-vous c'est juste pour voir l'impacte sur la mémoire.

[hegros]

Et quand la fonction est recursive, que se passe-t'il?

C'est un cas particulier, pour printf je veux bien qu'on me prouve et explique clairement le contraire ne serait-ce qu'avec un bout de code simple.

Code :

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

1
2
3
4
5
6
7
8
9
10
#include<stdio.h>
 
int main(void) {
 
printf("Bonjour\n");
printf("Hello\n");
printf("Bonjourno\n");
printf("Kornichoah\n");
return 0;
}

[Médinoc]

Code X :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
; Listing generated by Microsoft (R) Optimizing Compiler Version 14.00.50727.762 

	TITLE	d:\MesDocs\Visual Studio 2005\Projects\FbtUtil\DvpCom\printf.c
	.686P
	.XMM
	include listing.inc
	.model	flat

INCLUDELIB LIBCMTD
INCLUDELIB OLDNAMES

PUBLIC	??_C@_0M@NFGECFDE@Kornichoah?6?$AA@		; `string'
PUBLIC	??_C@_0L@CIKEKAPD@Bonjourno?6?$AA@		; `string'
PUBLIC	??_C@_06NJBIDDBG@Hello?6?$AA@			; `string'
PUBLIC	??_C@_08HIKGINMF@Bonjour?6?$AA@			; `string'
PUBLIC	_main
EXTRN	_printf:PROC
EXTRN	__RTC_CheckEsp:PROC
EXTRN	__RTC_Shutdown:PROC
EXTRN	__RTC_InitBase:PROC
;	COMDAT ??_C@_0M@NFGECFDE@Kornichoah?6?$AA@
; File d:\mesdocs\visual studio 2005\projects\fbtutil\dvpcom\printf.c
CONST	SEGMENT
??_C@_0M@NFGECFDE@Kornichoah?6?$AA@ DB 'Kornichoah', 0aH, 00H ; `string'
CONST	ENDS
;	COMDAT ??_C@_0L@CIKEKAPD@Bonjourno?6?$AA@
CONST	SEGMENT
??_C@_0L@CIKEKAPD@Bonjourno?6?$AA@ DB 'Bonjourno', 0aH, 00H ; `string'
CONST	ENDS
;	COMDAT ??_C@_06NJBIDDBG@Hello?6?$AA@
CONST	SEGMENT
??_C@_06NJBIDDBG@Hello?6?$AA@ DB 'Hello', 0aH, 00H	; `string'
CONST	ENDS
;	COMDAT ??_C@_08HIKGINMF@Bonjour?6?$AA@
CONST	SEGMENT
??_C@_08HIKGINMF@Bonjour?6?$AA@ DB 'Bonjour', 0aH, 00H	; `string'
CONST	ENDS
;	COMDAT rtc$TMZ
rtc$TMZ	SEGMENT
__RTC_Shutdown.rtc$TMZ DD FLAT:__RTC_Shutdown
rtc$TMZ	ENDS
;	COMDAT rtc$IMZ
rtc$IMZ	SEGMENT
__RTC_InitBase.rtc$IMZ DD FLAT:__RTC_InitBase
; Function compile flags: /Odtp /RTCsu /ZI
rtc$IMZ	ENDS
;	COMDAT _main
_TEXT	SEGMENT
_main	PROC						; COMDAT

; 4    : {

	push	ebp
	mov	ebp, esp
	sub	esp, 192				; 000000c0H
	push	ebx
	push	esi
	push	edi
	lea	edi, DWORD PTR [ebp-192]
	mov	ecx, 48					; 00000030H
	mov	eax, -858993460				; ccccccccH
	rep stosd

; 5    : 	printf("Bonjour\n");

	push	OFFSET ??_C@_08HIKGINMF@Bonjour?6?$AA@
	call	_printf
	add	esp, 4

; 6    : 	printf("Hello\n");

	push	OFFSET ??_C@_06NJBIDDBG@Hello?6?$AA@
	call	_printf
	add	esp, 4

; 7    : 	printf("Bonjourno\n");

	push	OFFSET ??_C@_0L@CIKEKAPD@Bonjourno?6?$AA@
	call	_printf
	add	esp, 4

; 8    : 	printf("Kornichoah\n");

	push	OFFSET ??_C@_0M@NFGECFDE@Kornichoah?6?$AA@
	call	_printf
	add	esp, 4

; 9    : 	return 0;

	xor	eax, eax

; 10   : }

	pop	edi
	pop	esi
	pop	ebx
	add	esp, 192				; 000000c0H
	cmp	ebp, esp
	call	__RTC_CheckEsp
	mov	esp, ebp
	pop	ebp
	ret	0
_main	ENDP
_TEXT	ENDS
END

[Jean-Marc.Bourguet]

C'est un cas particulier, pour printf je veux bien qu'on me prouve et explique clairement le contraire ne serait-ce qu'avec un bout de code simple.

Essaie. objdump permet aussi de deassembler si ma memoire est bonne.

[hegros]

Arf, ce n'est pas clair du tout désolé

Le code assembleur dépend de trop de chose pour m'y fier, pareil pour déssembler.

Une référence quelque part peut être ?

[astrotouf]

dans le code exécutable on voit clairement que le code de printf a été recopié autant de fois qu'elle a été apellée. non?

[Jean-Marc.Bourguet]

dans le code exécutable on voit clairement que le code de printf a été recopié autant de fois qu'elle a été apellée. non?

Non, on voit que le code est partage. C'est tout l'interet d'avoir des fonctions.

[astrotouf]

d'accord mais vous n'avez toujours pas repondu à ma question je la réecris :
lorsqu'on utilise une bibliothèque comme GTK+, je pense que dans ce cas on l'utilise de manière dynamique puisqu'il faut un runtime pour faire marcher les programmes GTK+ ?
est-ce-que les librairies utilisées par la bibliothéque sont totalement chargées en mémoire (glib, pango ...etc) ou est ce qu'elle ne charge que les choses les plus nécessaires (les fonctions appelées dans notre code source)?
voyez-vous c'est juste pour voir l'impacte sur la mémoire.

[Neitsa]

lorsqu'on utilise une bibliothèque comme GTK+, je pense que dans ce cas on l'utilise de manière dynamique puisqu'il faut un runtime pour faire marcher les programmes GTK+ ?
est-ce-que les librairies utilisées par la bibliothéque sont totalement chargées en mémoire (libg, pango ...etc) ou est ce qu'elle ne charge que les choses les plus nécessaires (les fonctions appelées dans notre code source)?
voyez-vous c'est juste pour voir l'impacte sur la mémoire.

Sous Windows, GTK+ est effectivement disponible en bibliothèque dynamique (*.dll). J'imagine que les bibliothèques dont dépend GTK+ sont elles aussi dynamiques (pour la simple nécessité de réutilisation qui ne nécessite pas d'avoir à embarquer tout le code de chaque bibliothèque).

Lorsque l'on appelle une fonction d'une bibliothèque dynamique c'est toute la bibliothèque dynamique qui est disponible pour le processus, même si on appelle qu'une seule fonction de celle-ci.

Raison première : Certaines fonctions ou variables internes (non exportées) à une bibliothèque doivent être accessible à une fonction exportée.

Pour prendre un cas sous Windows (mais j'imagine que cela s'applique à tous les O.S d'aujourd'hui). [les noms sont fantaisistes]

La bibliothèque dynamique GTKplus.dll à un lien sur pango.dll et sur Cairo.dll. Alors oui, le programme nécessitant ces bibliothèques dynamiques va charger GTKplus.dll en mémoire. Le chargeur (loader) s'apercevant que GTKplus.dll nécessite pango.dll et Cairo.dll alors il charge celles-ci aussi en mémoire (i.e : dans l'espace d'adressage du processus).

Là où les O.S actuels sont performants, c'est qu'en réalité, il n'existe qu'une seule version de ces bibliothèques dynamiques pour tous les processus du système.

Tous les processus nécessitant GTKplus.dll et sa cohorte de DLLs n'auront pas alloués chacun de la mémoire pour chacune de ces DLLs.

Elles existent (les DLLs) physiquement une seule fois en mémoire et sont partagées entre les espaces d'adressage. [raccourcis que les puristes me pardonneront, mais l'idée générale est là].

[Jean-Marc.Bourguet]

La lib va se trouver complètement dans l'espace virtuel du process. Ensuite, il y a de bonnes chances qu'elle ne va pas être complètement chargée, seules les pages nécessaires à l'initialisation et qui contiennent du code appelé devraient être chargées réellement en mémoire. Et les pages contenant du code devraient être partagées entre tous les process qui utilisent la lib.

[astrotouf]

d'accord. comment un programme qui utilise GTK+ sait que la DLL qu'il veut utiliser est déjà en mémoire et qu'il n'a pas à la recharger du disque dur?
c'est le système d'exploitation qui s'en charge?