afx_msg
-
Was bedeutet afx_msg vor Funktionen? Ist das nur ein Hinweis für den Anwendungsassistenten oder hat das eine reale programmiertechnische Bedeutung?
P.S.: Warum sind solche Funktionen nicht virtual?
-
Drück doch einfach mal F12, dann siehst Du was afx_msg bedeutet...
Und die Methoden sind i.d.R. in einer Basisklasse "virtual" markiert und brauchen deshalb in der abgeleitet Klasse nicht nochmals als solches markiert werden (eine der schwächen der Sprache C++
)
-
Na super!
#ifndef afx_msg #define afx_msg #endifZum virtual: Die Funktion DoDataExchange ist aber auch schon in CDialog virtual und trotzdem wird sie nochmal explizit so deklariert. Wie kommt das? Gibt es dafür einen speziellen Grund oder ist das Microsoft-Willkür?
-
NES-Spieler schrieb:
Zum virtual: Die Funktion DoDataExchange ist aber auch schon in CDialog virtual und trotzdem wird sie nochmal explizit so deklariert. Wie kommt das? Gibt es dafür einen speziellen Grund oder ist das Microsoft-Willkür?
Nein, das ist C++ Chaos...
-
NES-Spieler schrieb:
Was bedeutet afx_msg vor Funktionen? Ist das nur ein Hinweis für den Anwendungsassistenten oder hat das eine reale programmiertechnische Bedeutung?
P.S.: Warum sind solche Funktionen nicht virtual?
Weil diese nicht über einen vtable angesprochen werden, sondern über eine MessageMap. Es gab in den Entwurfszeiten der MFC einige Diskussionen wie man mit Windowsnachrichten umgehen soll. Man entschied sich dann weiterhin bei dem Konzept für mit einer zentralen WindowProc zu bleiben und die Nachrichten auch klassisch über MAPs (nichts anderes als bessere switch/case Blöcke) zu verteilen.
Übrig geblieben ist dann die Definition afx_msg, die andeuten soll (mehr aus Dokumentationsgründen), dass diese Funktion in einer Messagemap verwendet wird und somit über ein entsprechendes Routing über WindowProc's die Klasse erreicht. Außer ganz wenigen Funktionen wie OnCommand, OnOK, OnCancel, OnInitDialog sind kaum virtuelle Funktionen vorhanden, die letzten Endes auf eine Windows Nachricht zurückgehen. Zudem wollten die MFC Entwickler nicht das Windows Nachricten Konzept ersetzen.
Ein Konzept mit virtuellen Funktionen hätte bei der aktuell behandelten Anzahl von Windows Nachrichten ein gigantisches aufblähen der EXEs durch vtables zur Folge gehabt. Jede abgeleitete CWnd Klasse würde für alle bekannten Windows Nachrichten einen vtable Eintrag erben... Zudem wäre es ein Problem beliebige freie Nachrichten abzufangen, die nicht vordefiniert sind. Man wäre um das Konzept eine WindowProc in der dann alle nicht durch existierende virtuelle Funktionen behandelten Einträge eine Nachbehandlung erfahren.
Just my 2 cents.
