L'OS charge-t-il les fonctions d'un programme dans la RAM ?
Que devienne les fonctions definit mais non utilisées ? Car les fonctions non apelées n'ont aucun interet ds un programme (sauf pour les DLLs) donc je voulais savoir si j'avais à m'inquiéter en ce qui concerne le poid de l'executable et la RAM utilisé lorsque je créer un fonction...
Merci

C'est une bonne question dont j'aimerais bien connaitre la reponse

une fonction ca pese pas lourd, en taille mémoire, bien moins que les inévitables données...

tout depend de ton environnement.
si tu es sur PC, c'est royal donc la taille du code est pas primordiale.
si tu es dans l'embarqué, vaut mieux tout optimiser sinon tu feras vite de la chasse à l'octet. bien sur, dans ce cas tu es obligé de faire un compromis entre place memoire et vitesse d'execution.

pour exécuter un programme, l'OS crée un processus.
Dans l'espace d'adressage du processus, il y a notament un segment text, qui contient le code.
l'OS mappe en mémoire certaines parties de l'espace d'adressage du processus, qui sont utilisé pour l'exécution.
Si tu n'utilises pas une fonction, elle ne sera pas dans l'exécutable, donc pas dans l'espace d'adressage, donc pas dans la RAM.
C'est différent pour les librairies dynamiques, le fonctionnement est trop dépendant de l'OS, je crois, pour pouvoir généraliser ...
Z3RgSp4wN> tu cherches à prendre un cours d'info accéléré ?

et dans le cas où une fonction inutilisée se retrouverait dans le binaire du process, la pagination de l'os pourrait permettre d'évincer la page mémoire de la fonction si elle est n'est jamais touchée.
mais bon ça doit arriver rarement...

disons que la fonction est rarement utilisé, et que la page est rarement demandée alors.

voy

Si la fonction n'est pas utilisée, elle est tout simplement éjectée par le compilateur, du moins elle devrait l'être.

+1
Mais surtout comment veux-tu que l'OS détecte une fonction non utilisée dans un exe ? Une fois que c'est compilé, il voit ça comme un gros paquet de code exécutable.
Le loader charge l'exe au fur et à mesure des faults pages. Si tu suis le lancement d'un exe avec un soft genre filemon qui traque le moindre accès disque, tu remarques le nombre de "pages" de 4Ko de l'exe qui sont lues au fur et à mesure de son exécution. C'est d'ailleurs pour ça que les exe compressés c'est mal car là tout est décompressé et présent en mémoire et l'OS ne peut pas paginer.
Une autre discussion précédente m'a laissé penser que Windows savait détecter la non utilité de certains modules mappés dans un exe, avec les fonctions graphiques et GDI quand la fenêtre est minimisée par exemple. Car il diminue alors la taille du working set du process, c'est à dire qu'il autorise des bouts de ce dernier à être viré de la RAM.

Je n'ai pas entendu parler de modules. Un source en C est composé de fichiers qui seront compilés en modules objets. On peut imaginer que des compilos soient assez intelligents pour ne pas compiler certaines fonctions déclarées en "static" mais l'intérêt est très limité, pour le reste, le compilo ne peut pas deviner si la fonction sera utilisée ou non par un autre module.
Toutes les fonctions seront donc présentes dans le module objet et intégrés dans des librairies (statiques ou DLL). Si une seule des fonctions existantes dans un module est appelée, le linkeur chargera l'ensemble du module qui sera donc présent dans le fichier exécutable ou en DLL externe.
Quant aux DLL sous Windows, l'OS les charge intégralement en RAM et non pas chaque module séparément (XP : lancer msinfo32.exe et aller dans Environnement logiciel / Modules chargés, y'a du monde).
En conclusion, si la taille du code exécutable est une priorité, il faut fractionner son source en modules séparés (fichier .c) notamment pour l'écriture de bibliothèques de fonctions, pratiquement un module par fonction...

pour les DLLs c'est pas parceque elle sont visibles qu'elles consomment des pages physiques, la pluspart des OS essayent de faire les choses à la demande.

Le terme module, je l'ai utilisé au sens module Windows, c.a.d essentiellement un fichier PE (exe, dll, ocx, ...)
Ces modules ne sont pas chargés intégralement en mémoire. Rienq ue les resources embarquées par exemple sont chargées à la demande.  

Avec une lib statique, ca fait longtemps que les smart linker ne link que ce qui est nécessaire.

pas compris.

Au point de vue code source, que tu ait 100.000 lignes de code dans 1 seul fichier ou 10.000 fichiers de 10 lignes ça revient au même, il faut compiler 100.000 lignes de code. Au linking un smart linker dégage tout seul ce qui n'est pas utilisé, donc je comprends pas ta conclusion.

merci pour toute ces infos quelqu'un n'aurait pas un URL sur lequel je pourrait m'informer de comment marche les executable en mémoire ce qu'est une page... comment tout ça fonctionne en approfondie svp? Pour éviter de poser des questions sur ce forum...

Z3RgSp4wN> des bouquins si tu veux ?
 
je crois que pour les librairies statiques, on est d'accord, si le linker fait bien son boulot, il n'y a pas de code inutile dans les exécutables.
Par contre les fichiers objet contiennent le code qu'on lui a demandé de compiler! meme les fonctions static "au sens C" (désuete en C++ au passage si c'est bien de cet utilisation de static dont lsdyoyo parle. Celles-ci sont compilées mais ne sont pas exportées).
Après pour les libs dynamiques, il y a pas mal d'OS qui utilise le mappage de fichiers. Les fichiers à mapper sont les bibliothèques dynamiques. L'OS mappe donc la lib dynamique, et fait en sorte de fixer les bonnes permissions  pour que d'autres processus puissent partager le code de la lib (on dit mapper aussi je crois, mais c'est pas terrible).
 
Pour en revenir à la question de départ, il ne faut pas présupposer qu'on a à faire a tel ou tel OS. Le principe de compilation, linkage, librairies statique et dynamique est bien fait et permet de se concentrer sur le C++, en faisant abstraction de l'environnement d'exécution.

A un niveau au dessus, on fait aussi largement abstraction du mécanisme de gestion de la mémoire virtuelle. On fait confiance à ce mécanisme qui va évincé les pages inutilisés ...

C'est quoi la mémoire virtuelle ? (en vite fait)

en vite fait, l'OS fait comme s'il avait beaucoup plus de mémoire qu'il n'en a réellement (physiquement).

c'est un espace de mémoire, découpé en pages qui peut être ou non en mémoire physique.
 
----------
 
c'est comme les clusters de la fat pour un disque dur, ton fichier quand tu le charges, c'est séquentiellement, mais en fait il peut être éclaté en petites portions sur tout la surface du disque (et donc ton application peut lire séquentiellement un fichier, mais le dur va pas arrêter des faire des allez-retours).  
 
-----
 
en gros ça permet:
 
1) séparer les espaces de travail entre les process (il ne peuvent pas se taper dessus les uns sur les autres)
 
2) de retarder le plus tard possible la consommation de la mémoire (tu peux allouer 1Go de ram sur une machine qui n'a que 64Mo, tant que tu te balades pas dans le Go, rien ne sera consommé)
 
3) gagner de l'espace mémoire physique, car par exemple plusieures ressources physiques peuvent être partagées via plusieurs espaces mémoire virtuels
 

le 1 Go de ressource il ne le stocke pas entierement en mem vive c'est ça ?!

valà, il y a un roulement des ressources qui est faite derrière.

Ok merci pour l'explication (même si certains vont piquer un crise parceque je cherche pas toujours sur google) ^^

c'est quoi au fait le rapport avec la cat o_O