Version imprimable
Bonjour,
J'ai un petit soucis concernant mon gestionnaire de mémoire.
En effet, j'obtient une erreur de link LNK2005 sur afxmem.lib stipulant que l'opérateur new(unsigned int) existe déjà dans un module (un a moi)
J'imagine que c'est parce que afx possède une gestion de la mémoire également et donc a redéfinit le même opérateur que moi, donc le projet se retrouve avec deux définitions d'une même méthode...
Que puis-je faire ?
Merci,
A bientôt
forcer un "rebuild all", peut être une référence à un mauvais new() restant dans un objet de ton projet
J'ai essayé et ça n'a rien changé
Ne pas redéfinir ton opérateur pour les unsignes int ?
Ne pas utiliser afx ? Voire s'il ne contient pas une macro à même de désactiver sa gestion mémoire ?
A part ces deux solutions, je ne vois pas trop. Comment voudrais-tu que ton code réagisse quand il y a new unsigned int(42) dedans ?
Avec un peu de chance, tu ne veux en fait redéfinir l'allocation que pour un petit nombre de classes à toi, et pour leurs classes dérivées. Dans ce cas, tu peux redéfinir l'operateur new pour ces classes-là, ce qui t'évitera ce type de conflits.
Carl
Oui pour le branchement de mon gestionnaire, j'inclu un fichier pour l'activer au début de mon implémentation et un pour le désactiver à la fin, pour que ça reste que dans mes classes.
J'ai vu dans les options du projet l'inclusion des MFC (soit dans une bibliothèque statique, soit dans une DLL partagée).
J'ai essayé de mettre l'option d'inclusion dans une DLL partagée et ça fonctionne.
Par contre, lorsque je quitte mon programme, c'est long car AFX génère une très grande liste de leaks...
Je ne comprends pas pourquoi il y a autant de leaks en liant les MFC en DLL partagée et pas en librairie statique.
Avez-vous une idée ?
Merci beaucoup,
A bientôt
Comment "détectes" tu les leaks ?
C'est le debug-spew ? Dans ce cas, une DLL et un EXE n'on pas les même points d'entrée pour commencer le debug mémoire et l'arrêter... il se peut que des variables statiques (et MFC les aime) conserve de la mémoire allouée...
Sinon, pour le probleme de new, je vois pas trop comment tu fais pour l'activer à un endroit et le désactiver plus tard... De toute manière, tes unités de compilation sont indépendantes, tu n'as donc pas besoin de "désactiver"....
Quant aux new/delete de MFC, il me semble (mais c'est plus un vague souvenir qu'autre chose) qu'il existait un #define à utiliser... genre: NO_AFX_MALLOC ou un truc du genre. Mais je peux me gourrer
En fait, j'ai le même soucis que lui :
http://public.kitware.com/Bug/view.php?id=3834
Pour détecter les leak, j'ai un gestionnaire de mémoire qui fait les allocation et qui en même temps stock les pointeurs/taille/fichiers et ligne dans le fichier.
Lors que je fais un "delete", ça retire l'enregistrement de l'allocation.
Lorsque le programme se ferme, ça reprend les allocations enregistrées (où il y a eu un new et pas de delete) et ça les inscrit dans un fichier.
Je redéfinit donc les opérateurs.
Code:inline void* operator new(std::size_t stSize, const char* szFilename, unsigned int uiLine, const std::string sFunction)
Puis je fais de define pour utiliser ces opérateursCode:inline void operator delete(void* pvPointer) throw()
Le new ne pose pas de problème quant aux arguments que j'aiCode:
2
3
Par contre le delete pose un soucis étant donné que les MFC possède aussi ce delete.
J'ai tenté d'ajouter des paramètres dans mon delete pour avoir un prototype différent et que ça compile mais rien à faire, ça passe toujours par celui d'afx...
Ca me soule trop, j'arrête de perdre du temps là dessus et j'ai encore l'impression qu'une fois qu'on met un pied dans les trucs microsoft, faut y mettre tout le reste et utiliser leurs salopries.
C'est faux pour pas mal de trucs, mais c'est le cas pour MFC: MFC est un framework complet, pas une simple bibliothèque.