intrigue sur la surcharge du new et delete

Version imprimable

06/09/2006, 15h55
swirtel

intrigue sur la surcharge du new et delete

bonjour,

quelques questions se posent lorsque je pense à la surcharge du new et delete.

je vois dans la majorité des exemples que le new et delete sont substitués par un malloc et un free.

problème, comment peut-on faire en sorte que le constructeur de la classe ou le destructeur soient bien appelés avec la surcharge des deux opérateurs ?

merci
06/09/2006, 15h57
Médinoc

Le langage appelle le constructeur après le retour de operator new.

Je reprend l'exemple que Loulou24 a donné dans son tutorial sur la création d'un moteur 3D en C++.
http://loulou.developpez.com/tutorie...artie1/#L2.2.1
Code:

1 2 3 4 5 6 7 8 9 10 11 inline void * operator new( size_t ) { void * p = malloc( size ); /// je fais des choses :d return p; } inline void operator delete( void * p ) { /// je fais des choses :d free( p ); }
Est-ce que le langage va directement appeler le constructeur ou le destructeur lorsque je ferai appel à ces opérateurs surchargés ?

Merci

06/09/2006, 16h28
Jean-Marc.Bourguet

Si tu fais:

Code:

X* x = new X;

oui, si tu fais

Code:

X* x = operator new(sizeof X);

non.
06/09/2006, 16h28
dabeuliou

Oui.

je viens de vite faire un test avec l'exemple suivant, et il semblerait qu'effectivement mon constructeur et destructeur sont bien appelés.

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
 
#include <iostream>
#include <memory>
 
inline void * operator new( size_t t ) {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
    return malloc( t );
}
 
inline void operator delete( void * p ) {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
    free( p );
}
 
struct Test {
    Test() {
        std::cout << __PRETTY_FUNCTION__ << std::endl;
    }
    ~Test() {
        std::cout << __PRETTY_FUNCTION__ << std::endl;
    }
};
 
int main()
{
    std::auto_ptr< Test > ( new Test() );
	return 0;
}

confirmation de votre part ? et est-ce qu'il y a possibilité d'utiliser autre chose que le malloc ?

merci

06/09/2006, 16h42
Laurent Gomila

Citation:

confirmation de votre part ?

Pour la troisième fois... Oui.

Citation:

et est-ce qu'il y a possibilité d'utiliser autre chose que le malloc ?

Tout ce que tu veux du moment que tu renvoies un pointeur sur un espace mémoire valide pour la taille demandée.
Tu peux utiliser les fonctions de ton OS (mais de toute façon les malloc et compagnies finissent par y passer) ; ou encore dans des cas plus particulier tu peux utiliser des pools (mémoire pré-allouée dans laquelle tu ne fais que piocher).
06/09/2006, 16h43
swirtel

Bon, je viens de tester et effectivement cette technique ( celle donnée par Loulou24 ) semble intéressante.

Je rappel que la technique expliquée par Loulou24 donne la possibilité de tracer les (dés)allocations à l'aide d'un gestionnaire de mémoire.

Par contre, elle ne me semble pas appropriée avec l'utilisation de pointeur intelligent et surtout lorsque l'on réalise un release du pointeur encapsulé.
06/09/2006, 17h20
loufoque

Citation:

Je rappel que la technique expliquée par Loulou24 donne la possibilité de tracer les (dés)allocations à l'aide d'un gestionnaire de mémoire.

Pas besoin de ça pour tracer les allocations mémoire.
06/09/2006, 18h02
dabeuliou

@loufoque > Peux-tu en dire un peu plus sur les autres moyens d'y parvenir ?
07/09/2006, 00h31
loufoque

La plupart des outils de profiling doivent faire des choses semblables.
07/09/2006, 13h31
dabeuliou

Oui, sauf que dans la solution proposée par Loulou, il est possible de générer un rapport des memory leak après chaque utilisation du logiciel. J'entends par là qu'aucun autre outil n'est nécessaire que le programme lui-même.
Sa méthode permet aussi de vérifier qu'un pointeur pointe sur une zone mémoire correctement allouée. Disons qu'avec cette méthode assez simple à mettre en oeuvre, on peut avoir des infos en debug sans nécessiter de fermer le programme, ouvrir un outil de profiling, reproduire le problème, etc...
07/09/2006, 15h23
loufoque

Citation:

Oui, sauf que dans la solution proposée par Loulou, il est possible de générer un rapport des memory leak après chaque utilisation du logiciel. J'entends par là qu'aucun autre outil n'est nécessaire que le programme lui-même.

C'est sûr que si tu te refuses d'utiliser les outils appropriés pour tester ton logiciel, c'est pas pareil.

Citation:

Sa méthode permet aussi de vérifier qu'un pointeur pointe sur une zone mémoire correctement allouée. Disons qu'avec cette méthode assez simple à mettre en oeuvre, on peut avoir des infos en debug sans nécessiter de fermer le programme, ouvrir un outil de profiling, reproduire le problème, etc...

Je vois pas en quoi c'est plus compliqué avec un outil comme valgrind.
Je tape valgrind chemin/vers/mon/application et ça lance l'application normalement et en même temps il m'informe de tous les problèmes niveau mémoire, et pas seulement ceux que j'ai programmé.