opérateurs New et Delete
Le
MGN
Bonjour,
étant potentiellement confronté à un problème de mémoire insuffisante en cas
d'utilisation des opérateurs new et delete,
j'ai dans l'idée de redéfinir des opérateurs New et Delete (implémentés
comme fonctions membres static pour certaines classes), qui seraient
attachés à des blocs de mémoire éventuellement réservés sur le disque (en
dernier recours).
(nota : je préfère ne pas redéfinir les opérateurs new et delete => à moi de
faire attention)
Avez-vous déjà fait cela et si oui, avez-vous des liens vers des exemples ?
Merci à vous.
Marc
étant potentiellement confronté à un problème de mémoire insuffisante en cas
d'utilisation des opérateurs new et delete,
j'ai dans l'idée de redéfinir des opérateurs New et Delete (implémentés
comme fonctions membres static pour certaines classes), qui seraient
attachés à des blocs de mémoire éventuellement réservés sur le disque (en
dernier recours).
(nota : je préfère ne pas redéfinir les opérateurs new et delete => à moi de
faire attention)
Avez-vous déjà fait cela et si oui, avez-vous des liens vers des exemples ?
Merci à vous.
Marc
Poser une question
Tu ne peux pas definir d'operateurs autres que ceux prevus par le langage.
Je suppose que tu veux faire des fonctions qui renvoient un proxy
(vraisembablement ayant un operator-> en plus pour la facilite
d'utilisation). A chaque acces, le proxy verifie si l'objet est reellement
en memoire ou pas, auquel cas il le charge.
Il va te falloir un deuxieme niveau d'indirection pour etre notifie de la
fin des expressions (et eviter que dans des expressions complexes, tu ne
recuperes de la memoire en cours d'utilisation).
En passant, avec le controle sur l'overcommit qui est global pour le
systeme plutot que local a chaque application, c'est difficile d'etre sur
qu'une allocation a reussit meme si elle renvoie qqch de non nul.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++...index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
C'est vous qui voyez. Y'en a qu'ont essayé :)
"Modern C++ etc." par Andrei Alexandrescu pour la surcharche des
operateurs (si tu changes d'avis) et pour des exemples d'allocateurs
par block ...
Je n'ai pas compris ça. J'ai supposé qu'il voualit allouer de la
mémoire dans une mmap() par exemple.
[snip]
--
Michael
Pourrais-tu en dire plus ?
oui bien sûr et je réalise que si la question n'est pas claire c'est que le
problème n'est pas clair dans ma tête (ou plutôt bien compliqué pour moi à
ce stade).
Pour simplifier :
j'ai des "petites" classes dérivées d'une classe de base CObject avec des
opérateurs redéfinis.
Par exemple CObject + CObject retourne un pointeur CObject* alloué dans le
tas avec new.
Jusque là, pas de problème.
J'ai aussi défini de "gros" objets qui contiennent un vector<CObject*> (il
s'agit de champs de table pour fixer les idées), où la mémoire associée aux
objets de base est allouée dans le tas. Evidement, si la taille du champ
augmente, je peux avoir des problèmes de mémoire insuffisante. De plus il
peut y avoir des opérations entre champs, etc..
D'où mon idée (actuellement au stade conceptuel) :
définir un "opérateur" personnel New (avec l'"opérateur" Delete associé) qui
retournerait non pas une adresse mémoire valide mais un décalage dans une
plage. Cette plage serait "matérialisée" par une classe CMemory par exemple
(et utilisation du modèle singleton sans doute), capable de retrouver le
contenu d'un objet à partir de la valeur du décalage. Cette classe CMemory
pourrait le cas échéant lire la valeur à partir d'un fichier (et plus
généralement gérer les ressources mémoire réelles).
D'une manière générale, j'aimerais bien séparer les problèmes et ne pas
avoir à "gérer" les insuffisances de mémoire éventuelles dans ma hiérarchie
de classes dérivées de CObject.
A ce stade, je pressens que le plus gros problème si j'adopte cette solution
sera la gestion de la fragmentation et la libération de cette mémoire
"virtuelle".
Est-ce que vous avez connaissance d'une classe qui ferait ceci (l'équivalent
de la classe CMemory ci-dessus décrite)?
ps : j'ai aussi lu que l'allocation de petits objets avec new n'était pas
optimale
http://www.ensta.fr/~enstar/doc/c++/courscpp/Sections/Sect07-B9.html
d'où l'intérêt possible pour moi d'une telle classe, d'autant que j'ai déjà
pour tous mes objets des fonctions de lecture/écriture efficaces.
J'espère avoir été plus clair.
Marc
J'ai surtout l'impression que tu essaies de recréer à la main le
système de mémoire virtuelle qui existe déjà dans les OS modernes.
Un des trucs fondamentaux que j'ai appris en cours de maths : toute
proposition précédée du mot "évidemment" est probablement fausse.
Il faudrait que tu donnes plus de contexte : comptes-tu avoir besoin
d'adresser plus de 2 Go de mémoire, tout en restant en 32 bits ?
[Je parle bien de "mémoire" en général -- sa localisation
(RAM physique ou swap) n'est pas un paramètre auquel tu as accès.]
Si la réponse est "non", tu cherches des complications pour rien.
Si la réponse est "oui", pose-toi à nouveau la question. Le 32 bits
disparaît, lentement mais sûrement.
Peux-tu confirmer que tu as bien compris le contenu de cette page ?
http://varnish-cache.org/wiki/ArchitectNotes