Discussion :

[Clad3]

Bonjour à tous .
Dans le cadre d'un projet conséquen il parrait difficile de ne se passer totalement d'une gestion de la mémoire . Je me demande comment vous y parvenez, je serait surtout intéréssé par les libraries que vous utilisez ( si c'est le cas ... ), les "règles d'or" que vous respectez ...

Si ca peux aider, je compile sous windows avec VC++ 2003 , mais je tiens à ce que mon programme soit portable .

Sinon , j'ai vu qu'une librairie revenait pas mal de fois, le mémory manager de Fluid's Studio, vous en pensez quoi ? J'ai du mal à trouver un article conséquent dessus, détaillant son utilisation, ses pours et ses contres ...

Merci .

[aziz jim]

En ce qui concerne la gestion de la mémoire, j'éspère que ceci vous aidera:


http://haypo.developpez.com/article/halloc/

[ash.ice.loky]

Salut Clad3,

La gestion de la mémoire, tout un programme en C++
Je n’utilisais aucun gestionnaire jusqu'à ce qu’il me soit confié
De gros projets dans un cadre plus professionnel ou la tu ne dois pas te louper.
Je me suis alors dit faut ci mettre et depuis je ne ferais machine arrière pour rien.

A mes yeux il y a 2 outils indispensables :
- le Gestionnaire de mémoire (surcharge de new, delete, new[] et delete[])
- les pointeurs intelligents (donc plus de delete lol)

Je précise tout de suite que je possède ma propre version pour chacun de ces outils
Et que je ne peux donc pas te renseigner sur tel ou tel lib.

Le gestionnaire de mémoire :
- SUPER
- Tu inclus dans tous tes fichiers un petit entete GESTIONNAIRE_MEMOIRE.h
- Dans ton fichier principal (avec le main) tu
- #define ACTIVE_GESTIONNAIRE_MEMOIRE

Et c’est tout. Le reste est auto, et te sort en un fichier avec les fuites, libérations, et tout ce qui va avec.

Bien entendu cette méthode est valable pour mon gestionnaire mais ca doit être un peu partout pareil et surtout tu vois la simplicité du truc.

Une fois la version finale développé, tu remplace par :
- #define DESACTIVE_GESTIONNAIRE_MEMOIRE

Et voila une version optimisé (sans les tests donc).

Les pointeurs intelligents :
La j’avoue ne pas trop accrocher, j’ai mes propre pointeur intelligent, compatible Polymorphisme et STL mais ne gère pas les tableaux, mais tu les remplace par les vector
Donc pas de problème de ce coté la.

Le principal ennui est le remplacement des problèmes de new/delete par celui des
Compatibilité. Par exemple tu souhaites faire un gestionnaire de ressources, alors tu dois utiliser un pointeur différent car map< string, PoiteurIntel<ressource> >, par exemple ne libère jamais car par tu as déjà ton compteur a 1.

Et surtout tu te retrouve avec un code assez lourds avec des PoiteurIntel<XXX> partout, dans les définitions de méthodes, les déclarations, bref, tu ne doit plus avoir de * sous prétexte de mettre tes pointeurs dans le mur.

Du coup je suis pas trop pour cet outil.

[Luc Hermitte]

Les gestionnaires de mémoire pour débugguer, blinder et valider la gestion manuelle de la mémoire, pourquoi pas.. Ils servent aussi pour optimiser (mise en oeuvre de pools de buffers).
Par contre, je ne trouve pas que cela aide particulièrement à gérer la mémoire.

Au contraire des pointeurs intelligents. Ces derniers correspondent à l'application du RAII à la gestion de la mémoire. Et le RAII, c'est l'idiome, qui en C++, permet de gérer simplement des ressources dans le contexte où des exceptions peuvent survenir. Le gestionnaire de mémoire n'aide en rien du tout sur ce point critique.

La criticité du point ne correspond qu'à ma propre expérience. Au début le client teste l'outil dans les cas nominaux, puis il s'amuse à valider dans les cas à la noix (perte de réseau, plantage de process critiques à divers moments, réception de télémétrie corrompue, ...)
Là, la gestion des exceptions a intérêt à être carrée. Et le RAII aide bien pour cela.

[JolyLoic]

Je ne sais pas trop ce que vous entendez par "gestionnaire de mémoire", mais au cas où ce ne soit pas ça, je voudrais juste signaler qu'il existe aussi des garbage collectors en C++.

[Luc Hermitte]

J'ai repris la "définition" d'ash.ice.loky -> une couche qui détourne new/delete.