Optimisation de la mémoire

bonsoir à tous,

J'ai une petite question qui me tracasse ...
Quelle méthode vous parait la plus optimisée pour la gestion de la mémoire

Code:

---

1 2 3 4 5

char chaine[50];   strncpy(chaine, "un simple exemple", 50); /* on laisse la mémoire être vidée à la terminaison du programme */

---

ou bien

Code:

---

1 2 3 4 5

char *chaine;   chaine = strdup("un simple exemple"); free(chaine);

---

Ma question vous parait peut être idiote mais dans le cas du 1er exemple on alloue un espace mémoire de 50 caractères, ceci même si le mot qu'on y copie n'en fait pas autant, puis dans l'exemple 2, seul l'espace mémoire dont j'ai besoin va être alloué grâce a strdup.
Donc pour vous, quelle méthode est la plus propre, la plus optimisée en terme de gestion de la mémoire.

Merci à vous pour vos futurs explications

Salut,

Ca dépend de l'usage que tu comptes faire de cette chaine. Si c'est une constante, il faut la déclarer en tant que telle. Si c'est le résultat d'une saisie, il faut réserver l'espace pour la plus grande saisie autorisée. Si elle fait partie d'un dictionnaire lu d'un fichier, strdup me parait bien.

A+

Pfeuh

Options non-indiquées dans le premier message:

Code:

---

1 2 3 4 5

/*Constante pure*/ char const * chaine = "un simple exemple";   /*Buffer avec pile la bonne taille*/ char chaine[] = "un simple exemple";

---

Options dans un cadre un peu différent puisqu'il s'agit alors d'initialisations et non d'affectations.

Ah, en effet.

D'un autre côté, la première peut être une affectation (mais pas la seconde).

merci pour vos réponses

Dans le cas du 1er exemple, l'espace pré-alloué est limité a 50 caractères, si je n'en copie que 10 avec un strncpy(), l'espace restant il fini ou ? il est vidé automatiquement ? si oui, du coup il n'y a pas vraiment d'avantage a utiliser strdup() , a part s'il y a une taille maxi imposée ? J'me suis dit que je pourrai combiner les 2 en écrivant une fonction strdup qui prendrai également comme argument une taille maximum

Code:

---

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

char *string_copy(char *dest, const char *src, size_t size) { const char *end = dest + size; char *copy = dest;   while (*src && dest < end) *dest++ = *src++;   *dest = 0; return copy; }     char *string_dup(const char *src, size_t maxsize) { char *ret = NULL; size_t size = strlen(src);   if (size > maxsize) size = maxsize;   ret = malloc(size + 1);   if (ret) string_copy(ret, src, size); else abort();   return ret; }

---

Code:

---

1 2	chaine = string_dup("un simple exemple", 50);

---

au final es-ce que ca en vaut la peine d'après vous ? J'essai simplement de gérer la mémoire au mieux, si vous me dites qu'il n'y a pas réellement d'intêret et que les 2 méthodes citées en début de poste sont plus ou moins equivalentes je lacherai l'affaire ...

Merci à vous

Il y a des fois où ça peut être intéressant, mais c'est rare.

PS: C'est assez dérangeant que dans ta première, size ne comprenne pas le \0 terminal.

Salut,

merci, j'vais donc virer tout ce code superflu

Citation:

---

Envoyé par Ganondorf

merci pour vos réponses

Dans le cas du 1er exemple, l'espace pré-alloué est limité a 50 caractères, si je n'en copie que 10 avec un strncpy(), l'espace restant il fini ou ? il est vidé automatiquement ?

---

Salut

Ca signifie quoi "vider un espace mémoire" ? Un espace mémoire a toujours une valeur (soit utile, soit résiduelle issue d'autre chose). Il ne peut donc jamais être vide !!!

"liberée" si tu préfères ...

Citation:

---

Envoyé par Ganondorf

"liberée" si tu préfères ...

---

Ce n'est pas que je préfère ou pas ; c'est que si tu prends de suite conscience de certains faits, peut-être que certaines de tes préoccupations s'envoleront toutes seules.
Si tu alloues 50 caractères ben tu as un espace de 50 caractères comme demandé. Il n'y a aucune raison que, si tu n'en utilises que 10 les 40 autres soient automatiquement libérés. D'ailleurs, du point de vue du compilo, ça signifie quoi "utiliser" ???

Citation:

---

Envoyé par Sve@r

Si tu alloues 50 caractères ben tu as un espace de 50 caractères comme demandé. Il n'y a aucune raison que, si tu n'en utilises que 10 les 40 autres soient automatiquement libérés.

---

C'est pour ca que je demandai si allouer la mémoire dynamiquement ce n'est justement pas moins couteux en espaces mémoire (puisque j'alloue uniquement ce dont j'ai besoin). En déclarent un espace mémoire statique cela me donne juste une espace a ne pas dépasser, si j'alloue un espace de 50 caractères et que je n'en utilise que 10 au final j'ai alloué trop de mémoire, même si c'est infime sur l'exemple que j'ai donné.
Mais bon au final j'ai trouvé ma réponse sur wikipedia

Citation:

---

L'avantage de l'allocation statique se situe essentiellement au niveau des performances, puisqu'on évite les coûts de l'allocation dynamique à l'exécution : la mémoire statique est immédiatement utilisable.

---

L'article parle aussi d'allocation sur la pile, de quoi s'agit-il ?
Merci à vous d'avoir prit le temps de me renseigner.

Citation:

---

Envoyé par Ganondorf

C'est pour ca que je demandai si allouer la mémoire dynamiquement ce n'est justement pas moins couteux en espaces mémoire (puisque j'alloue uniquement ce dont j'ai besoin).

---

De façon générale, quand on écrit un code, on alloue uniquement ce dont on a besoin. Et si la taille est connue dès le départ, malloc est alors totalement inutile. Voire même dégradant tant en terme de code et de tests à effectuer (vérifier l'allocation réussie) qu'en temps d'exécution (l'allocation étant dynamique, la mémoire est réservée au moment de l'exécution et il faut alors au processeur le temps de la trouver).

Et donc ton premier exemple char chaine[]="..." correspond exactement à ce que tu décris => tu ne réserves que ce dont tu as besoin. Maintenant, si un peu plus tard dans le code tu y mets une chaine plus petite via strncpy() cela ne regarde que toi. Idem si tu cherches à y mettre une chaine plus grande...

Le malloc/realloc ne se justifie que lorsque la taille de la zone n'est pas connue lorsque le code est écrit. Et dans ce cas, on subdivise encore les cas. Si la taille peut être calculée en une fois, alors un malloc() unique sera plus adéquat. Si au contraire la zone à stocker croît de façon régulière, alors le realloc sera obligatoire. Et dans ce dernier cas, le realloc étant très lourd (si le proc ne peut pas agrandir la zone il doit alors en donner une autre puis tout copier de l'ancienne vers la nouvelle) il sera bon de travailler par blocs (on alloue N et ensuite on remplit jusqu'à ce que N soit atteint et si on dépasse on réalloue N de plus...).

Citation:

---

Envoyé par Ganondorf

L'article parle aussi d'allocation sur la pile, de quoi s'agit-il ?

---

La mémoire d'un programme se subdivise en 2 zones
- la pile, qui est l'endroit où sont mises les variables classiques d'un programme. On y trouvera ta chaine de ton premier exemple, les paramètres des fonctions, bref toutes les variables classiques quoi.
- le tas qui est un gros bordel. Comme son nom l'indique, c'est un immense "tas" dans lequel on alloue et on libère de la mémoire sans se soucier de ce qu'il y a autour. C'est là que le malloc/realloc vient se servir

Avantages et inconvénients: la pile est bien ordonnée, compacte. Les variables y sont "empilées" dans l'ordre de leur création et libérées dans l'ordre inverse. C'est d'ailleurs pour ça qu'on doit déclarer ses variables au début de tout bloc (quoique depuis qq temps cette contrainte ait été abolie par les compilos modernes). De plus elle est très très rapide et les variables sont automatiquement libérées en fin de bloc. Mais elle n'est pas énorme (enfin elle supporte quand-même des tableaux de taille "raisonnable").
Le tas, lui, peut être vu comme illimité. Mais il est lent (chaque allocation engendrera tout un tas de routines de recherche et de réservation d'espace libre), peut même à long terme être trop fragmenté pour être efficace (surtout si on fait du malloc/free de façon anarchique).
De plus, tout bloc alloué doit impérativement être libéré manuellement (normal, le proc ne sait pas quand un bloc n'est plus utile). A une époque pas si lointaine, sous les vieux Windows, une allocation non libérée était définitivement perdue même après la fin du programme ayant provoqué l'allocation (nécessité alors de redémarrer la machine). Ce problème a disparu soit avec NT, soit avec 2000 (à vérifier). Mais au-moins, un bloc alloué par une fonction X peut être utilisé par une fonction Y (pour peu que la fonction Y sache où se trouve ledit bloc)...

merci beaucoup d'avoir prit le temps de m'expliquer tout ca, intuitif et très intéressant.

Oui, merci beaucoup pour la dernière explication très claire et intéressante à propos de la gestion de la mémoire.
Sujet qui soulevait des questions que je me posais également, ravi que quelqu'un ait demandé à ma place : )