Ist es eine gute Idee, Win32-Header neu zu erstellen?

7

Ich finde, dass ich in letzter Zeit mehr C / C ++ - Code gegen Win32 mache und aus einem C # -Hintergrund heraus eine Besessenheit mit "sauberem Code" entwickelt habe, die völlig konsistent ist, also weg vom schönen System. * -Namespace zurück zum Mischmasch von #defines, die die Win32-API-Header-Dateien bilden, ist ein bisschen ein Kulturschock.

Nachdem ich die alphanumerische Liste der Kernfunktionen von Win32 durchgelesen hatte, erkannte ich, wie einfach Win32s API-Design tatsächlich ist, und es ist bedauerlich, dass es mit all den Problemen der letzten 25 Jahre überzogen ist, einschließlich vieler Referenzen auf 16-Bit-Programmierung irrelevant in der heutigen 64-Bit-Welt.

Ich werde bald ein neues C / C ++ - Projekt starten, und ich habe darüber nachgedacht, wie ich die Win32-Header nach Bedarf neu erstellen kann. Ich könnte es entwerfen, um schön zu sein, und dennoch würde es 100% binäre (und Quell-) Kompatibilität mit vorhandenen Programmen aufrechterhalten (weil die #defines schließlich dasselbe lösen).

Ich habe mich gefragt, ob jemand das in der Vergangenheit versucht hat (Google hat nichts gefunden), oder wenn jemand mich davon abhalten wollte.

Eine andere Sache, an die ich dachte, war, wie mit einer saubereren Win32-API es möglich wird, einen saubereren und einfach zu verwendenden C ++ - Win32-API-Wrapper oben zu entwerfen, da es keine Namespace-Verschmutzung vom alten C Win32 geben würde Gegenstände.

BEARBEITEN:

Nur um zu verdeutlichen, dass ich das nicht mache, um die Kompilierungsleistung oder für irgendeine Art von Optimierung zu verbessern, bin ich mir vollkommen bewusst, dass der Compiler auf alles verzichtet, was nicht verwendet wird. Meine Aufgabe hier ist es, eine Win32-Header-Bibliothek zu haben, mit der es eine Freude ist, mit ihr zu arbeiten (weil ich nicht jedes Mal Caps-Lock drücken muss, wenn ich eine Funktion verwende).

    
Dai 27.05.2011, 01:38
quelle

6 Antworten

10

Tu das nicht.

Es ist möglich, aber es wird eine lange Zeit dauern und wird wahrscheinlich zu kleinen Fehlern führen.

Aber, und was noch wichtiger ist, es wird Ihr Programm absolut unmöglich machen, außer für Sie.

    
SLaks 27.05.2011, 01:44
quelle
3

Es hat keinen Sinn, das zu tun. Nur weil es zusätzlichen Gruft gibt, bedeutet das nicht, dass es in die Binärdatei kompiliert ist (alles, was nicht verwendet wird, wird optimiert). Außerdem, auf der EXTREME-Off-Chance, dass sich etwas ändert (ich weiß nicht, vielleicht WM_INPUT die Zahl ändert) ist es viel einfacher, die System-Header zu verwenden. Was ist noch intuitiver? Ich denke #include <windows.h> ist viel einfacher zu verstehen als #include "a-windows-of-my-own.h" .

Außerdem sollten Sie sich ehrlich gesagt niemals den Inhalt von windows.h anschauen. Ja, ich habe es gelesen, ja, es ist hässlich wie die Sünde, aber es tut, was ich brauche, und ich muss es nicht aufrechterhalten.

Wahrscheinlich ist der einzige Nachteil der Verwendung der realen windows.h , dass es die Übersetzung um einige Millisekunden verlangsamen kann.

    
Chris Eberle 27.05.2011 01:43
quelle
3

Nein. Was ist der Punkt? Fügen Sie einfach <windows.h> ein und definieren Sie einige Makros wie WIN32_LEAN_AND_MEAN , VC_EXTRALEAN , NOGDI , NOMINMAX usw., um Dinge zu entfernen, die Sie nicht benötigen / brauchen, um Ihre Kompilierungszeiten zu beschleunigen.

    
Adam Rosenfield 27.05.2011 01:44
quelle
3

Obwohl die Win32-Header als "unordentlich" betrachtet werden, müssen Sie nie wirklich in sie hineinschauen (oder wollen). Alles, was Sie wissen müssen, ist im Win32-SDK dokumentiert. Der genaue Inhalt der Header-Dateien ist ein Implementierungsdetail.

Es gibt eine Menge Dinge, die zeitaufwändig und unnötig kompliziert zu replizieren wären, insbesondere in Bezug auf verschiedene Versionen des Win32 SDK.

Ich empfehle:

%Vor%     
Greg Hewgill 27.05.2011 01:48
quelle
2

Meiner Meinung nach ist das eine schlechte Praxis. Ordnung und Kürze werden erreicht, indem die Standardpraxis so weit wie möglich beibehalten und so viel wie möglich von der Plattform genutzt wird. Sie müssen davon ausgehen, dass Microsoft über die ultimative Expertise in ihrer eigenen Plattform verfügt, wobei einige Aspekte über das hinausgehen, was Sie gerade wissen. In einfachen Worten, es ist ihr Produkt und sie wissen es am besten.

Indem Sie Ihre eigenen rollen:

  • ... Sie verzweigen von der Microsoft-API, damit Microsoft Ihnen keine Updates mehr über ihre Standard-Channels bereitstellen kann
  • ... Sie können Fehler aufgrund Ihrer eigenen Hybris einführen, weil Sie das Gefühl haben, etwas herausgefunden zu haben, während Sie es nicht haben
  • ... Sie würden viel Zeit für keinen greifbaren Vorteil verschwenden (da die C-Header keinen Overhead in die kompilierte Binärdatei tragen)
  • ... Sie würden schließlich ein weniger elegantes Projekt erstellen

Der eleganteste Code ist einer, der mehr LOC der tatsächlichen Programmlogik und so wenig wie möglich LOC für "Housekeeping" (d. h. Code, der nicht direkt mit der Aufgabe in Verbindung steht) trägt. Versäumen Sie nicht, die Platform SDK-Header zu nutzen, um Ihr Projekt eleganter zu gestalten.

    
Ilya 27.05.2011 01:53
quelle
1

Dies wurde in der Vergangenheit versucht.

In seinem include -Verzeichnis enthält MinGW eine eigene Version von windows.h . Vermutlich existiert dies, um die Header mit gcc arbeiten zu lassen. Ich weiß nicht, ob es mit einem Microsoft-Compiler funktioniert.

    
David Grayson 27.05.2011 07:07
quelle

Tags und Links