Discussion :

[Médinoc]

Oui.

[astrotouf]

Ok et bien merci !!! c'était trés concis

[hegros]

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

Pas pour vous blesser mais c'est complétement inintéressant de montrer du code assembleur pour 'expliquer clairement' ce qui se passe.

Ne connaissant que trés peu l'assembleur, les demandeurs et intervenants à majorité également je pense, que voulez-vous qu'on en fasse ?

Médinoc inline n'est pas dans le vocabulaire du langage C il me semble tu confonds avec les macros.

[Jean-Marc.Bourguet]

Pas pour vous blesser mais c'est complétement inintéressant de montrer du code assembleur pour 'expliquer clairement' ce qui se passe.

J'ai du mal à voir ce que montrer clairement ce qui se passe peut signifier d'autre que regarder le code machine final.

Médinoc inline n'est pas dans le vocabulaire du langage C il me semble tu confonds avec les macros.

inline est un mot clé en C depuis 1999.

[hegros]

J'ai du mal à voir ce que montrer clairement ce qui se passe peut signifier d'autre que regarder le code machine final.

En le commentant ca peut être intéressant mais brut ca fais plus peur qu'autre chose je trouve.

inline est un mot clé en C depuis 1999.

Ah d'accord, je ne suis pas obstineux.

[Médinoc]

Ne connaissant que trés peu l'assembleur, les demandeurs et intervenants à majorité également je pense, que voulez-vous qu'on en fasse ?

Voir qu'il n'y a rien dedans qui ressemble à une copie du code d'une grande fonction comme printf(), et voir les quatre "call _printf" dans le code : Quatre sauts vers le code de la fonction

Médinoc inline n'est pas dans le vocabulaire du langage C il me semble tu confonds avec les macros.

Je connais la différence entre fonctions inline et macros, mais je me suis demandé si tu ne confondais pas toi-même en disant que le code des fonctions était recopié à chaque appel.

[astrotouf]

je suis content ! c'est le premier sujet que je poste et qui gagne autant de succès.
c'est vrai que seules les fonctions inline sont remplacées par leur code à chaque appel.
voila un lien qui l'explique de manière explicite :
http://membres.lycos.fr/dancel/cplus...s/fonct40.html

Mais je croyais que le mot clé inline était défini qu'à partir de C++ ??
je me trompe ??

[hegros]

Voir qu'il n'y a rien dedans qui ressemble à une copie du code d'une grande fonction comme printf(), et voir les quatre "call _printf" dans le code : Quatre sauts vers le code de la fonction

Je pense que si tu crois que c'est clair pour tout le monde alors tu te trompes.

Sans vantardise, cela fait plus de 8ans maintenant... on va dire que je fais de la programmation et ce n'est pas clair du tout.

inline et macro sont quasi-identiques pour moi et remplissent en tout cas la même fonction.

[hegros]

Vous avez raison c'est bien cela j'ai fais une confusion.

Mais vraiment les commentaires manquent je trouve, en tout cas cela ne m'a pas éclairé, en tout cas de suite.

[hegros]

Mais je croyais que le mot clé inline était défini qu'à partir de C++ ??
je me trompe ??

inline est un mot clé en C depuis 1999.

[Emmanuel Delahaye]

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

Euh, non. Seul l'appel est répété. La fonction n'est présente qu'une seule fois dans la bibliothèque statique qui est liée à l'application (sauf si le compilateur décide d'inliner les fonctions courtes comme strcpy(), memcpy() etc.)

[hegros]

Euh, non. Seul l'appel est répété. La fonction n'est présente qu'une seule fois dans la bibliothèque statique qui est liée à l'application (sauf si le compilateur décide d'inliner les fonctions courtes comme strcpy(), memcpy() etc.)

Oui j'ai répondu déja à cela.

Sinon je n'ai jamais dis que la fonction était présente plusieurs fois dans la bibliothéque.

Et effectivement c'est plus en rapport avec le inline ce que j'ai rapporté.

Sinon pour les fonctions récursives il y avait quelque chose de particulier ?

[Emmanuel Delahaye]

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

Ce n'est pas une question de langage C. C'est un problème de système, d'exécutable, de bibliothèques partagées ou non... Il n'y a pas de réponse 'C'. Tout ce qu'on peut dire d'ici est 'ça dépend de l'implémentation'... Certains systèmes gèrent mieux la mémoire que d'autres. Ce n'est pas le lieu pour en débattre.

[Emmanuel Delahaye]

En le commentant ca peut être intéressant mais brut ca fais plus peur qu'autre chose je trouve.

Bah, il est déjà commenté. Voici la partie intéressante qui montre clairement qu'il y a 4 appels à printf() :

Code :

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

[hegros]

Et le code de printf c'est ce qu'il y a tout à la fin ?

[Emmanuel Delahaye]

Et le code de printf c'est ce qu'il y a tout à la fin ?

Non. Le code de printf est dans la bibliothèque. Ce que montre l'assembleur, c'est le résultat de la traduction du (supposé) main.c de C en assembleur. Pour voir le printf() , il faudrait désassembler le .exe... Bon courage, parce que dans ce sens là, il n'y a évidemment aucun identificateur. Que des adresses (relatives) 'en dur'...

Ce qu'il y a à la fin, d'après le nom de la fonction c'est un appel à une fonction 'système C' (RTC = Run Time C-library) qui vérifie si la pile a explosé ou non (Check SP, avec SP = Stack Pointer)...

[hegros]

C'est pas clair pour moi ne connaissant pas l'assembleur, c'est pour cela que je disais que l'exemple n'est pas forcément le meilleur.

La bibliothéque est dynamique alors??????

[Emmanuel Delahaye]

C'est pas clair pour moi ne connaissant pas l'assembleur, c'est pour cela que je disais que l'exemple n'est pas forcément le meilleur.

La bibliothéque est dynamique alors??????

Bah non. Elle est statique, mais elle n'est pas dans main.c... 'Compilation séparée', ça te parle ?

[hegros]

On ne doit pas parler de la même chose alors.

Dans l'executable final, on ne retrouve bien qu'une fois le code binaire de printf bien qu'on l'appelle x fois dans le programme ?

Du coup la liaison statique perd, de mon point de vue, tout son sens...

[Emmanuel Delahaye]

On ne doit pas parler de la même chose alors.

Dans l'executable final, on ne retrouve bien qu'une fois le code binaire de printf bien qu'on l'appelle x fois dans le programme ?

Oui, tout à fait., comme déjà indiqué :

Pour voir le printf() , il faudrait désassembler le .exe

Du coup la liaison statique perd, de mon point de vue, tout son sens...

Bah, je ne vois pas pourquoi. Elle fait exactement ce pourquoi elle a été faite.