Non pas du point de vue de la facilité d'utilisation, mais du point de vue des performances. Les mappages de messages MFC sont-ils plus rapides qu'une boucle de messages typique ?
Réponses
Trop de publicités?Ils ne peuvent pas être plus rapides car ce ne sont qu'un wrapper autour des pompes à message Windows normales. Cela dit, ils aident beaucoup avec les messages réfléchis et l'encapsulation de la pompe à message des contrôles personnalisés, et les frais généraux sont négligeables, donc cela pourrait en valoir la peine à long terme si vous avez un projet d'interface utilisateur compliqué.
Je dois contredire les 2 autres répondants qui prétendent que la boucle des messages MFC est moins performante simplement parce qu'elle enveloppe des boucles de messages C ordinaires : MFC utilise une technique très différente qu'une simple procédure de fenêtre contenant une énorme instruction switch(message).
La boucle des messages MFC repose en effet sur la boucle des messages Win32 (elle doit le faire). Mais l'implémentation est très différente : basée sur des crochets, la distribution des messages est gérée en interne par MFC plutôt que de s'appuyer sur l'API DispatchMessage().
MFC utilise des maps pour assortir les messages aux gestionnaires : O(log n). De ce point de vue, il pourrait y avoir des cas où cela est plus rapide qu'une instruction mal compilée switch(message) : O(n).
De plus, il pourrait être plus rapide d'identifier le bon objet fenêtre que DispatchMessage(), ce que nous ne pouvons pas savoir avec certitude car Windows n'est pas open source.
Cependant, cela est peu probable, notamment en tenant compte du code supplémentaire, tel que le routage des commandes, le traitement des inactivités et divers cas particuliers gérés par le code MFC... et du fait que les compilateurs sont suffisamment intelligents pour implémenter efficacement de grandes switch()
!
Cela étant dit, l'impact sur les performances n'a pas été considéré comme significatif depuis plus de 15 ans.
Serge a écrit:
La pompe de messages MFC repose en effet sur la boucle de messages Win32 (il le faut). Mais l'implémentation est très différente: basée sur des hooks, la distribution des messages est gérée en interne par MFC plutôt que de s'appuyer sur l'API DispatchMessage().
Je ne suis pas sûr que cela soit correct. Si vous regardez à l'intérieur du fichier MFC thrdcore.cpp, vous verrez cette fonction:
BOOL AFXAPI AfxInternalPumpMessage()
{
_AFX_THREAD_STATE *pState = AfxGetThreadState();
.......... snip ...........
// traiter ce message
if (pState->m_msgCur.message != WM_KICKIDLE
&& !AfxPreTranslateMessage(&(pState->m_msgCur)))
{
::TranslateMessage(&(pState->m_msgCur));
::DispatchMessage(&(pState->m_msgCur));
}
return TRUE;
}
Cette fonction est appelée par la fonction MFC PumpMessage et comme vous pouvez le voir, elle utilise l'API DispatchMessage Win32, tout comme n'importe quelle autre application Win32.