Verwendung von HINSTANCE__...



  • Patrick den Code auf diesem Screenshot solltest du aber verbessern:

    http://trash.germangamedev.de/msvcpp2005e_tutorial_pictures/vc_download_040.jpg

    HINSTANCE__ ➡ HINSTANCE



  • ,,,,,,,,,,,,,

    typedef HINSTANCE__ *HINSTANCE;
    

    Ich hab es nicht so mit typedefs 😉 Ich will direkt und ohne Umwege sehen wo ein Pointer/Handle ist und wo nicht 😉 Ist Geschmackssache, aber falsch ist der Code nicht. Er ist genau so richtig wie die andere Variante 🙄



  • Und wenn der Typ dahinter mal geändert werden sollte?



  • Damit lehrst du anderen schlechten Stil! Selbst kannst du es ja gerne machen. 😉



  • ,,,,,,,,,,,,,
    Das ist ein Allroundargument. Das wurde ich auch schon gefragt wieso ich anstatt eines LPARAMs einen long _w64 lParam benutze. Oder einen unsigned long anstatt eines DWORDs. Da wird mit absolut hoher Wahrscheinlichkeit nicht mehr so viel geändert wie zum Sprung von 3.11 auf 95, 98 und NT4. Das einzigste was sich im Laufe der Zeit geändert hat ist, dass ein __w64 dazu gekommen ist. Das ist aber auch alles.

    Außerdem hat das einen Vorteil: Bei Präsentationen muß man dann nicht mehr im Zeitdruck (15 Min für die gesamte Präsi) nicht noch erklären was ein LPARAM/WPARAM/DWORD usw. ist und begründen wieso man diese Namen gewählt hat usw.

    Klar das eine hat auch seine Vor- und Nachteile, aber das ist eine Diskusion die nichts bringt. Das ist genau so eine Diskusion wieso einige { direkt hinter dem Prozedur-/Funktionskopf schreiben oder andere erst einen Absatz einfügen bevor das { eingefügt wird.

    Soll jeder tun wie er will: Es ist beides richtig. 😉

    Ob das nun guter oder schlechter Stil ist, steht nicht mal Ansatzweise zur Debatte.



  • Patrick schrieb:

    ,,,,,,,,,,,,,

    typedef HINSTANCE__ *HINSTANCE;
    

    Ich hab es nicht so mit typedefs 😉 Ich will direkt und ohne Umwege sehen wo ein Pointer/Handle ist und wo nicht 😉 Ist Geschmackssache, aber falsch ist der Code nicht. Er ist genau so richtig wie die andere Variante 🙄

    Naja, ioch würde sagen, das der Code 100%ig falsch ist. Zumindest wenn Du die WinAPI verwendest. Hier solltest Du nur Dinge verwenden, die Dokumentiert sind!
    Es wäre wirklich schön, wenn die Screenshots nicht leute durcheinander bringen.



  • Patrick schrieb:

    Das ist ein Allroundargument. Das wurde ich auch schon gefragt wieso ich anstatt eines LPARAMs einen long _w64 lParam benutze. Oder einen unsigned long anstatt eines DWORDs. Da wird mit absolut hoher Wahrscheinlichkeit nicht mehr so viel geändert wie zum Sprung von 3.11 auf 95, 98 und NT4. Das einzigste was sich im Laufe der Zeit geändert hat ist, dass ein __w64 dazu gekommen ist. Das ist aber auch alles.

    Hättest Du immer nur LPARAM verwendet, hättest Du die Probleme gar nicht...



  • Jochen Kalmbach
    Was für Probleme? Die eine stelle, das war eine Sache von weniger als 1 Sekunde. Also bitte, wo ist das Problem? Gab keines. Und zu Win98 Zeiten hab ich nur eine Applikation für Win32 gemacht. Also keine Probleme.

    Und falsch ist er nicht, da es das selbe ist wie beim typedef. Dazu stimmt die Doku mit den Typen auch nicht immer 100%ig, in meiner MSDN steht z. B. noch immer das HINSTANCE ein void* ist.

    Also bitte, wie kann man sich nur an so etwas "aufgeilen"? Das ist doch genau der unsinn wie "Benutz ich nun D3DVALUE oder float in Direct3D?".

    Das bringt es doch nicht mal Ansatzweise. Und verwirrt? Hmn, wäre mir neu wenn das jemanden verwirrt hat? 😮



  • Das Problem ist nur:
    Du verwendest Dinge die nicht dokumentiert sind.

    Das mag für Dich kein Problem sein, aber jemand der neu anfängt, der fragt sich was denn das ganze sein soll...
    Auch kann MS die von dir verwendeten Definitionen ändern oder einfach entfernen. Das mag für Dich auch kein Problem sein, aber wenn Du grosse Projekte hast, hast Du einen ziemlich hohen Aufwand.
    Genau das ist ja mit LPARAM bzw. WPARAM passiert. MS hat hier die Definition mit Einführung von x64/IA64 geändert. Wer dann nicht konsequent das verwendet hat, hat ein Problem mit der Umstellung nach x64/IA64.

    Was Du den Leuten zeigst ist total verwirrend, da es mit keiner Doku von MS übereinstimt; das ist IMHO das Problem.



  • Jochen Kalmbach
    Also im privaten sowie gewerblichen Projekten gab es da bei mir und meinen Teams nie sonderliche Probleme. Um genau zu sein: Gar keine.

    Und ich bin ehrlich: Ich kenne bisher keinen der gesagt hat (registrierter User) "Hey, das verwirrt mich aber."

    Wie schon gesagt: Geschmackssache. Falsch ist der code nicht, da es der selbe Typ ist den Du auch benutzt und gut ist. Und das Microsoft noch tiefgründigere Änderungen macht in diesem Bereich mit _w64 bzw. _w128 halte ich für die nächsten Jahre mehr als nur unwahrscheinlich.



  • Es ist auf jeden Fall niemanden so zu Empfehlen wie Du programmierst. Und ich finde es schaden, dass Du dieses Screenshot in Deiner sonst guten Anleitung drin hast.



  • Patrick kann man eh nicht überzeugen. Die Diskussion mit ihm ist ziemlich sinnlos. 😃 👍



  • Jochen Kalmbach
    Jedem das Seine 😉 Ich bin mir sicher, würdest Du mir etwas Code von Dir geben, hätte ich auch was auszusetzen. Aber ist das nicht irgendwie normal bei jedem Code? Es soll jeder für sich selbst entscheiden wie er es macht, denn: Es gibt viele Wege die nach Rom führen 😉

    Kenner des Patrick
    Ziemlich subjektive Aussage, die nicht mal zutrifft 😉



  • Und was soll dann dieses hier?

    // Der Funktionspointer
    typedef int (__stdcall*msgbox)(HWND, LPCSTR, LPCSTR, UINT);
    

    Das verwirrt total. Warum schreibst du nicht:

    typedef int (__stdcall*msgbox)(HWND__*, const char*, const char*, unsigned int);
    

    Und überhaupt, wieso in aller Welt muß es ein typedef sein? Du sagtest doch, daß Du hinterher gar nicht mehr sehen kannst, worum es geht. Total unübersichtlich. Ein Cast an der richtigen Stelle löst das Problem sehr viel eleganter.

    Wenn Du schon nicht vernünftig programmieren willst, ziehe Deinen Style wenigstens durch. Mischmasch ist ja wohl das Allerletzte!



  • Und der Quellcode wird auch noch schlechter lesbar.



  • Pfosten
    Schau Dir das Datum der Codes an, bevor Du Dich noch lächerlich machst. Trollen ist öde, solltest Du wissen.

    Und das mit dem Thema "Vernünftig" stand bisher nicht zur Debatte. Aber bitte: Zeig mal einen "vernünftigen" Code von Dir, damit ich mich auch auf Deine Ebene herablassen kann. Sorry, aber für Kindergarten den Du veranstalten möchtest, habe ich keine Zeit.



  • Patrick schrieb:

    Aber bitte: Zeig mal einen "vernünftigen" Code von Dir, damit ich mich auch auf Deine Ebene herablassen kann.

    Gern, sehr vernünftig und ganz und gar ohne typedef:

    int (__stdcall* MyMessageBox)(HWND__*, const char*, const char*, unsigned int) = (int (__stdcall*)(HWND__*, const char*, const char*, unsigned int))GetProcAddress(dll, "MessageBoxA");
    

    Das ist völlig richtig so und in Richtung x64 wird sich bestimmt nichts weiter ändern. Und vor allem: Ohne typedef siehst Du sofort worum es sich dreht.



  • Ja, Nein, nun...als Anfänger möcht ich dazu sagen:
    "Das verwirrt mich" 😕

    Ich finde gerade die Typedefs machen die WinAPI Codes so kryptisch und unleserlich, und bauen eine Hemmschwelle für jemand der grad erst C++ gelern hat. Der denkt dann, "Wieso ist hier alles anders?"
    Ausserdem ist jegliches Codeschnippsel absolut unübertragbar ohne grössere Änderungsarbeiten.

    Darum:
    Wieso muss es ein UINT sein anstatt ein unsigned int ?
    oder noch übler ein VOID statt void
    und ein FALSE statt false?

    uawg



  • 1310-Logik
    Danke, das es mal einer auf den Punkt bringt. Danke.

    Pfosten
    Hast Du nicht eben gesagt, das dies nicht "vernünftiges Programmieren" ist? Komisch, das Du dann sowas vorweißt. Dazu: Wie wäre es mal registrieren? Als "Pfosten" kann sich ja jeder ausgeben. :p



  • Patrick schrieb:

    Das ist ein Allroundargument. Das wurde ich auch schon gefragt wieso ich anstatt eines LPARAMs einen long _w64 lParam benutze. Oder einen unsigned long anstatt eines DWORDs. Da wird mit absolut hoher Wahrscheinlichkeit nicht mehr so viel geändert wie zum Sprung von 3.11 auf 95, 98 und NT4. Das einzigste was sich im Laufe der Zeit geändert hat ist, dass ein __w64 dazu gekommen ist. Das ist aber auch alles.

    Ja, und irgendwann kommt _w128 und dann _w256 und dann ... Unter Portabilität versteht man eigentlich etwas anderes.

    Patrick schrieb:

    Außerdem hat das einen Vorteil: Bei Präsentationen muß man dann nicht mehr im Zeitdruck (15 Min für die gesamte Präsi) nicht noch erklären was ein LPARAM/WPARAM/DWORD usw. ist und begründen wieso man diese Namen gewählt hat usw.

    Du präsentierst deine Werke Linux Programmierern?

    Patrick schrieb:

    Klar das eine hat auch seine Vor- und Nachteile, aber das ist eine Diskusion die nichts bringt. Das ist genau so eine Diskusion wieso einige { direkt hinter dem Prozedur-/Funktionskopf schreiben oder andere erst einen Absatz einfügen bevor das { eingefügt wird.

    Naja, nicht wirklich. Das eine ist Codeformatierung, welche auf den Inhalt nicht den geringsten Einfluss hat. Du mit deinen Typen provozierst aber unnötig Inkonsistenz.

    Patrick schrieb:

    Und falsch ist er nicht, da es das selbe ist wie beim typedef. Dazu stimmt die Doku mit den Typen auch nicht immer 100%ig, in meiner MSDN steht z. B. noch immer das HINSTANCE ein void* ist.

    Genau deshalb nimmt man HINSTANCE, und nicht void*, HINSTANCE__ oder was auch immer. 😉 Stell dir den Typ wie eine black box vor, er hat einen bestimmten Zweck und wird situationsabhängig gebraucht. Was der Typ intern darstellt, weisst du aber nicht und hat dich auch überhaupt nicht zu interessieren. Zumal die Schnittstelle zur WinAPI ja nicht nur von Microsoft bereitgestellt wird (siehe zb MinGW). Du kannst also nicht immer davon ausgehen, dass der Typ HINSTANCE__ heisst. Der ist ja noch nicht mal dokumentiert. Vielleicht heisst er auch beim nächsten Release HINSTANCE___. Du siehst, verwende HINSTANCE und du entledigst dich all dieser Sorgen. Ausserdem sollte dir aufgefallen sein, dass der Bezeichner Unterstriche hat. Und solche Bezeichner sind idR der Implementation vorbehalten, also nicht dazu gedacht, von Clients benutzt zu werden.

    Patrick schrieb:

    Wie schon gesagt: Geschmackssache. Falsch ist der code nicht, da es der selbe Typ ist den Du auch benutzt und gut ist. Und das Microsoft noch tiefgründigere Änderungen macht in diesem Bereich mit _w64 bzw. _w128 halte ich für die nächsten Jahre mehr als nur unwahrscheinlich.

    Ja, und dass uns der Himmel auf den Kopf fällt auch. 🙄 Du solltest deine Argumentation wirklich nochmal überdenken.



  • groovemaster
    Nein, ich präsentiere das keinen Linuxprogrammierern sondern den Leutchen von der IHK, und ja: Ich musste das 1. mal begründen was das ist! Beim 2. mal hab ich Standardwerte genommen und Ruhe war.

    Und das mit "Ja, und dass uns der Himmel auf den Kopf fällt auch." empfinde ich als Wunschdenken. Dazu handelt es sich um eine Anfängerseite wo wie 1310-Logik es schon sagte, es ihn verwirrt das man UINT und co. benutzt.

    Also bitte, langsam wird es echt lächerlich mit dieser Diskusion. Das führt genau wieder zu so einer absurden Diskusion von wegen "size_t vs. unsigned long/int/short usw."


Anmelden zum Antworten