Une DLL MFC peut-elle créer plusieurs threads ?
À l’exception de l’initialisation, une DLL MFC peut créer en toute sécurité plusieurs threads tant qu’elle utilise les fonctions de stockage local de thread Win32 (TLS) telles que TlsAlloc pour allouer le stockage local du thread. Toutefois, si une DLL MFC utilise __declspec(thread) pour allouer un stockage local de thread, l’application cliente doit être implicitement liée à la DLL. Si l’application cliente lie explicitement la DLL, l’appel à LoadLibrary ne charge pas la DLL. Pour plus d’informations sur les variables locales de thread dans les DLL, consultez thread.
Une DLL MFC qui crée un thread MFC pendant le démarrage cesse de répondre lorsqu’elle est chargée par une application. Cela inclut chaque fois qu’un thread est créé en appelant AfxBeginThread ou CWinThread::CreateThread à l’intérieur :
D’un
InitInstanceCWinAppobjet dérivé dans une DLL MFC standard.Fonction Fournie
DllMainou RawDllMain dans une DLL MFC standard.Fonction RawDllMain fournie
DllMaindans une DLL d’extension MFC.
Une application multithread peut-elle accéder à une DLL MFC dans différents threads ?
Les applications multithread peuvent accéder aux DLL MFC régulières qui relient dynamiquement les DLL d’extension MFC et MFC à partir de différents threads. Une application peut accéder aux DLL MFC régulières qui relient statiquement MFC à MFC à partir de plusieurs threads créés dans l’application.
Existe-t-il des classes ou fonctions MFC qui ne peuvent pas être utilisées dans une DLL MFC ?
Les DLL d’extension utilisent la CWinAppclasse dérivée de l’application cliente. Ils ne doivent pas avoir leur propre CWinAppclasse dérivée.
Les DLL MFC régulières doivent avoir une CWinAppclasse dérivée -et un seul objet de cette classe d’application, comme pour une application MFC. Contrairement à l’objet CWinApp d’une application, l’objet CWinApp de la DLL n’a pas de pompe de message principale.
Notez que, étant donné que le CWinApp::Run mécanisme ne s’applique pas à une DLL, l’application possède la pompe de message principale. Si la DLL ouvre des boîtes de dialogue sans mode ou dispose d’une fenêtre de trame principale, la pompe de messages principale de l’application doit appeler une routine exportée par la DLL, qui appelle à son tour la CWinApp::PreTranslateMessage fonction membre de l’objet d’application de la DLL.
Quelles techniques d’optimisation dois-je utiliser pour améliorer les performances de l’application cliente lors du chargement ?
Si votre DLL est une DLL MFC normale qui est liée statiquement à MFC, la modification d’une DLL MFC standard liée dynamiquement à MFC réduit la taille du fichier.
Si la DLL a un grand nombre de fonctions exportées, utilisez un fichier .def pour exporter les fonctions (au lieu d’utiliser__declspec(dllexport)) et utilisez l’attribut NONAME du fichier .def sur chaque fonction exportée. L’attribut NONAME entraîne uniquement la valeur ordinale et non le nom de fonction à stocker dans la table d’exportation de la DLL, ce qui réduit la taille du fichier.
Les DLL qui sont implicitement liées à une application sont chargées lorsque l’application se charge. Pour améliorer les performances lors du chargement, essayez de diviser la DLL en dll différentes. Placez toutes les fonctions dont l’application appelante a besoin immédiatement après le chargement dans une DLL et que l’application appelante est implicitement liée à cette DLL. Placez les autres fonctions dont l’application appelante n’a pas besoin immédiatement dans une autre DLL et que l’application est explicitement liée à cette DLL. Pour plus d’informations, consultez Lier un exécutable à une DLL.
Il y a une fuite de mémoire dans ma DLL MFC standard, mais mon code semble correct. Comment puis-je trouver la fuite de mémoire ?
L’une des causes possibles de la fuite de mémoire est que MFC crée des objets temporaires utilisés dans les fonctions du gestionnaire de messages. Dans les applications MFC, ces objets temporaires sont automatiquement propre mis en place dans la CWinApp::OnIdle() fonction appelée entre les messages de traitement. Toutefois, dans les bibliothèques de liens dynamiques MFC (DLL), la OnIdle() fonction n’est pas appelée automatiquement. Par conséquent, les objets temporaires ne sont pas automatiquement propre mis en place. Pour propre des objets temporaires, la DLL doit appeler OnIdle(1) explicitement régulièrement.