2009-06-18 5 views
3

Très bien, j'ai une classe exportée dans une DLL. Cette classe a une liste de chaînes statiques, qui sont utilisées dans une zone de liste déroulante d'une boîte de dialogue dans le processus d'importation. Ces chaînes sont déclarées et définies comme suit:Variable de classe statique, exportée à partir de la DLL, s'affiche en tant que fuite de mémoire

// In header: 
class MYDLL_API someClass { 
public: 
    static const string stringList[]; 
    static const int numString; 
}; 

// In .cpp 
const int someClass::numString = 3; 
const string someClass::stringList[numString] = { 
    "String 1", 
    "String 2", 
    "String 3" 
}; 

Ainsi, l'exportation réelle fonctionne correctement. Cependant, j'ai remarqué mon VS 2008 vidage de la mémoire du débogueur qui est apparu comme

{129} normal block at 0x003D69F0, 32 bytes long. 
Data: <String 1> 

etc. 

Ainsi, afin de déterminer qui fuit cette mémoire je me suis arrêté de les utiliser dans la zone de liste déroulante qu'ils étaient destinés et vérifié pour voir si le la fuite était toujours présente, ça l'était. Donc ma question est, Y at-il un problème lié à l'exportation d'une variable de classe statique à partir d'une DLL, où il est considéré comme une fuite de mémoire?

Répondre

2

Ceci est probablement un problème avec l'ordre dans lequel les variables statiques sortent de la portée et quand les DLL sont déchargées (mfc/crt).

Jetez un coup d'œil à this - Il décrit à peu près le même problème que vous voyez.

Il existe également une solution proposée here, mais je ne sais pas si cela fonctionne. J'ai eu des problèmes comme ça par le passé et la seule façon de me débarrasser (proprement) de ces faux positifs est de les définir comme shared_ptr et de les détruire dans une méthode globale "shutdown" .

Questions connexes