Discussion :

[bolhrak]

Bonsoir tout le monde,

en suivant le tutoriel sur la conception des moteurs 3D de Laurent Gomilla, j'ai eu un problème avec le gestionnaire de mémoire. Celui-ci redéfinit les opérateurs new et delete de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
inline void* operator new(std::size_t size, const std::string& file, int line)
{
    return memorymanager::MemoryManager::GetInstance().allocate(size, file, line);
}
 
...
//code similaire pour les autres opérateurs

La fonction (static) pour récupérer l'instance de MemoryManager :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
MemoryManager& MemoryManager::GetInstance()
{
    static MemoryManager Instance;
    return Instance;
}

Le problème est que le MemoryManager contient une map et une stack comme attributs de classe, et que pendant l'initilisation de la map, un opérateur delete est appelé ; la variable Instance n'étant pas initialisée, il rappelle le constructeur et ça boucle infiniment.

Je cherche une astuce qui me permettrait de prendre en compte les opérateurs redéfinis une fois le MemoryManager initialisé.

Merci d'avance.

[Matthieu Brucher]

Utiliser un flag que tu mets à true une fois l'allocateur initialisé ?

[Laurent Gomila]

Dans le code je fais en sorte que ces surcharges ne soient justement pas prises en compte lors de la définition du gestionnaire de mémoire (en n'incluant pas l'en-tête qui les définit).

[bolhrak]

Deja merci pour vos reponses

Le fait est que je n'inclue pas la definition des operateurs dans le fichier de definition du gestionnaire de memoire. Du coup au moment de l'initialisation, lorsqu'un operateur new est appele, pas de probleme, il appelle bien l'operateur standard, par contre pour les appels a delete, il appelle bizarrement celui redefinit.

Ca marche effectivement en passant par un flag, bien que je ne trouve pas la solution tres elegante, mais bon a defaut de trouver mieux je vais faire comme ca :/

En tout cas je ne comprends pas pourquoi il utilise les operateurs delete redefinis meme la ou l'entete DebugNew.h n'est pas inclue.

P.S. : desole pour les accents, clavier qwerty du boulot.

[Laurent Gomila]

En tout cas je ne comprends pas pourquoi il utilise les operateurs delete redefinis meme la ou l'entete DebugNew.h n'est pas inclue.

Honêtement je n'ai jamais compris non plus.

Certains diront sûrement que ce genre de solution est "crade"; je suis globalement d'accord avec eux mais je n'ai jamais trouvé de solution de rechange qui soit aussi satisfaisante.

[bolhrak]

Bon ayant ressorti ma bonne vieille bible et ayant mis un peu plus les mains dans le camboui j'en arrive à d'autres questions sur le fonctionnement interne de ces opérateurs. Je préfère éviter de polluer le forum et continuer dans ce topic déjà résolu.

Donc ma première question : un appel à new pour la construction d'un objet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 X* p = new X;

va générer un appel à l'opérateur new de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 ::operator new(sizeof(X))

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

X::operator new(sizeof(X))

dans le cas de la redéfinition de cet opérateur pour la classe X. Or l'opérateur new retourne par définition un void* et le casting implicite d'un void* est interdit. Donc que se passe-t-il exactement ?

Deuxièmement, l'operator new se contente d'allouer de la mémoire sans l'initialiser, pourtant un objet construit via la ligne de code précédente est initialisé. Ma première intuition était que l'initialisation était effectuée une fois le pointeur retourné (qu'en fait l'appel a l'opérateur new se contentait de retourner le bloc de mémoire et que l'affectation à un objet de type X appelait le constructeur). Le problème est que cela ne colle pas avec un constructeur demandant des arguments :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

X* p = new X(integer, float)

Je continue avec une petite question concernant l'opérateur new de placement et la destruction des objets alloués de cette manière. Pour la partie allocation, dans le cas de l'opérateur new de placement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void* operator new(size_t size, void* p) {return p}

où se trouve l'allocation de mémoire ? Cet opérateur ne fait que retourner un bloc de mémoire passé en paramètres. Question subsidiaire, cet opérateur est généralement utilisé de la manière suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
void* buf = reinterpret_cast<void*>(0xF00F)
X* p = new(buf) X;

Comment est-on sûr que l'adresse passée en paramètre de l'opérateur :
1) est valide ?
2) est allouée ?

Pour la partie destruction, pourquoi un appel à l'opérateur delete ne peut être effectué sur un objet alloué de cette manière ? Dans la mesure où l'opérateur delete prend en argument le pointeur (donc l'adresse de l'objet), et où l'opérateur new de placement retourne le pointeur sur la zone mémoire contenant l'objet où est le problème ?

Enfin pour l'opérateur delete comment l'appel au destructeur est-il possible ? Cet opérateur prend un void* en paramètres ; de plus en redéfinissant cet opérateur de manière à ce qu'il se contente de libérer la mémoire via un appel a free, si l'on définit une hiérarchie de classe, on constate que les destructeurs des classes de base d'un objet sont quand même appelé. Comment cela peut-il se produire sans que cela ne soit codé explicitement, et surtout sans que l'opérateur delete ne connaisse ne serait-ce que le type de base de l'objet à détruire (cas dans lequel je comprendrais que cela est possible via la table de fonctions virtuelles) ?

[sergio.nogueira]

Le problème de la récursivité proviens en fait du std::stack. Je remplace simplement la std::stack par un std::vector. Du coup il faut remplacer les

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
 
m_DeleteStack.top() par m_DeleteStack.back()
 
m_DeleteStack.pop() par m_DeleteStack.pop_back();
 
m_DeleteStack.push(Delete) par m_DeleteStack.push_back(Delete);

Voila, normalement tout s'execute normalement.