MFC Application und die erstellte stdafx.h



  • Über die Jahre habe ich diverse MFC Applikationen erstellt.
    Ich habe die generierten stdafx.h Dateien der verschiedenen Projekte miteinander verglichen.

    Und frage mich nun wieso den hier jede anders aussieht. bzw. jede andere includes und defines hat.

    Ich habe aktuell eine MFC Static Lib erstellt. Hier ist die stdafx.h ziemlich schlank.

    In einer anderen MFC Anwendung ist hier viel mehr drin z.B.

    #ifndef _AFX_NO_OLE_SUPPORT
    #include <afxole.h>         // MFC OLE-Klassen
    #include <afxodlgs.h>       // MFC OLE-Dialogfeldklassen
    #include <afxdisp.h>        // MFC-Automatisierungsklassen
    #endif // _AFX_NO_OLE_SUPPORT
    
    #ifndef _AFX_NO_DB_SUPPORT
    #include <afxdb.h>			// MFC-ODBC-Datenbankklassen
    #endif // _AFX_NO_DB_SUPPORT
    
    #ifndef _AFX_NO_DAO_SUPPORT
    #include <afxdao.h>			// MFC-DAO-Datenbankklassen
    #endif // _AFX_NO_DAO_SUPPORT
    
    #ifndef _AFX_NO_OLE_SUPPORT
    #include <afxdtctl.h>		// MFC-Unterstützung für allgemeine Steuerelemente von Internet Explorer 4
    #endif
    #ifndef _AFX_NO_AFXCMN_SUPPORT
    #include <afxcmn.h>			// MFC-Unterstützung für allgemeine Windows-Steuerelemente
    #endif // _AFX_NO_AFXCMN_SUPPORT
    #include <afxdhtml.h>
    

    Woher kommt das ganze AFX Zeugs. Welche Einstellung generiert das?
    Woher kommen die unterschiede?



  • Alle bezeichner die da vorkommen kannst du googeln.
    Kommentare stehen auch bei jedem #include daneben.
    Und die Unterschiede kommen von unterschiedlichen Versionen des MFC-Projekt-Wizards und unterschiedlichen Einstellungen im Wizard beim Erzeugen des Projekts.



  • An den unterschiedlicheb versionen muss es wohl liegen.

    Gut mit den defines muss ich noch kämpfen:
    Wieso steht da überall NO

    also _AFX_NO_DAO_SUPPORT ->
    und der Kommentar dazu // MFC-DAO-Datenbankklassen

    No heißt doch kein also kein Support für dao. Der Kommentar sagt genau das Gegenteil.



  • Das "n" in "#ifndef" steht für "not". Und das "def" für "defined". (Und das "if" für "if" :D)

    #ifndef _AFX_NO_OLE_SUPPORT
    ...

    ==

    #if !defined(_AFX_NO_OLE_SUPPORT)
    ...

    Also wenn _AFX_NO_OLE_SUPPORT *nicht* definiert ist, dann das folgende Zeugs inkludieren. Logisch, oder?



  • Nein absolut nicht.!

    Also wenn nicht "nicht" dann inkludiere...



  • Was nicht, nicht logsich? Klar logisch.

    _AFX_NO_OLE_SUPPORT ist ein "opt out" makro.
    Damit sagst du "ich will bitte keinen OLE support".
    Wenn _AFX_NO_OLE_SUPPORT also nicht definiert ist, dann willst du OLE support, und dann inkludiert er die Files. Also wenn du NICHT sagst dass du es NICHT willst, dann bekommst du es halt.

    Was ist daran nicht logisch?



  • Wieso bitte eine doppelte verneinung.

    Wieso gibt an das man etwas nicht möchte. Dann muss man ja hunderte Dinge definieren die man nicht möchte.

    Wieso nicht

    #ifdef AFX_OLE_SUPPORT
    #include ...
    #endif
    

  • Mod

    Func()() schrieb:

    Wieso bitte eine doppelte verneinung.

    Wieso gibt an das man etwas nicht möchte. Dann muss man ja hunderte Dinge definieren die man nicht möchte.

    Wieso nicht

    #ifdef AFX_OLE_SUPPORT
    #include ...
    #endif
    

    Weil der Standard ist: "Man will es!"

    Wie soll man sonst mit dem setzen eines defines etwas verhindern, wenn der standard (Normalfall) es vorsieht...

    Es kommt immer auf den Standpunkt an! Defakto bringt es aber kaum was, wenn man diese Flags setzt. Die Größe der Anwendung wird davon nicht oder extrem wenig beeinflusst.

    Ich schmeiss immer alles raus und setze die includes, die ich brauche. mit den _AFX_NO_... defines arbeite ich gar nicht.



  • Hallo Martin

    Weil der Standard ist: "Man will es!"

    Ich habs ja schon verstanden. Für mich ist es halt verdrehte Logik. Ich hätte es anders rum gemacht.

    Es kommt immer auf den Standpunkt an! Defakto bringt es aber kaum was, wenn man diese Flags setzt. Die Größe der Anwendung wird davon nicht oder extrem wenig beeinflusst.

    Ich schmeiss immer alles raus und setze die includes, die ich brauche. mit den _AFX_NO_... defines arbeite ich gar nicht.

    Das hat wohl auch Microsoft eingesehen. Denn im neusten Wizard (VS2017) werden die ganzen _AFX_NO_ defines auch nicht mehr erzeugt.


  • Mod

    Func()() schrieb:

    Das hat wohl auch Microsoft eingesehen. Denn im neusten Wizard (VS2017) werden die ganzen _AFX_NO_ defines auch nicht mehr erzeugt.

    Nein das haben die nicht eingesehen, die haben den MFC code einfach nicht mehr so granular gemacht wie früher. Weil es keinen Sinn mehr machte oder den Aufwand nicht wert war (s.u.)
    IMHO war is mit VS-2010 vorbei mit kleinen MFC Programmen... danach war immer aller "Balast" drin, ob man ihn wollte oder nicht.

    Und der Kurs war auch klar: "Leute benutzt die Shared DLLs der MFC"!
    Das macht Speichernutzung effektiv, weil der Code geshared werden kann.
    Die EXE/DLL bleibt schön klein.

    Die Einführung der Manifeste für MFC und CRT sollte die Entwickler sogar zwingen. Das ganze war aber einfach ein Fehler und wurde ja auch rückgängig gemacht. Die damalige Diskussion ging ja auch in Richtung "Sicherheit". Man wollte es einfacher haben auch Sicherheitspatches für die CRT "grundsätzlich" auszurollen.

    War aber auch Quatsch: IMHO gab es keine Sicherheitspatches, die die MFC oder CRT an sich betrafen.

    Die Universal CRT ist dagegen ein vernünftiger Schritt... aber diente auch eigentlich eher um dem OS zentrale Funktionen der CRT kontrolliert zugänglich zu machen.

    Programmgröße und RAM spielen keine Rolle mehr. Wen scheren also 1MB COM/DAO/DB Geraffel. Zudem evtl. noch Seiten, die der Page Manager irgendwann wieder auslagert, weil diese nicht benutzt werden...

    Aber ich schweife ab.



  • Hallo Martin

    zurecht MVP 🙂

    Habe zwar einiges verstanden. Aber nicht alles. Muss ich auch nicht 🙂

    Danke dir.


  • Mod

    Func()() schrieb:

    zurecht MVP 🙂

    exMVP

    Nur der Vollständigkeit halber... 🕶


Anmelden zum Antworten