Das könnte eine dumme Frage für einige von euch sein und vielleicht habe ich diese Frage falsch gestellt, weil ich neu in C ++ bin. Aber ich merke, wenn Sie in vielen Win32-Anwendungen arbeiten, verwenden Sie eine Menge Ressourcen, die Zeiger sind. Warum müssen Sie immer einen Objektzeiger erfassen? Warum initiiere nicht eine neue Instanz der Klasse? und wenn ich davon spreche, bemerke ich in den meisten Fällen, dass Sie niemals neue Objekte initiieren, sondern immer Methoden aufrufen, die diesen Zeiger zurückgeben. Was ist, wenn dieser Zeiger irgendwo anders verwendet wird? Könntest du etwas kaputt machen, wenn du diesen Zeiger änderst und er woanders benutzt wird?
Windows-APIs wurden für C entwickelt, das die am häufigsten verwendete Sprache für die Systemprogrammierung war und immer noch ist; C-APIs sind der De-facto-Standard für System-APIs, und dafür haben und haben fast alle anderen Sprachen externe C-Funktionen aufzurufen. Daher ist das Schreiben einer C-API hilfreich, um mit anderen Sprachen kompatibel zu sein.
C APIs brauchen nur eine einfache ABI, die fast nur aus der Definition der aufrufenden Konvention besteht, die für Funktionen verwendet wird (und etwas über das Strukturlayout). C ++ und andere objektorientierte Sprachen hingegen erfordern eine komplexe ABI, die definieren muss, wie Objekte im Speicher abgelegt werden, wie Vererbung gehandhabt wird, wie die Vtable ausgelegt wird, wie Ausnahmen verbreitet werden, wo RTTI-Daten abgelegt werden, ... Darüber hinaus sind nicht alle Sprachen objektorientiert, und die Verwendung von APIs, die für C ++ mit anderen nicht objektorientierten Sprachen gedacht sind, kann ein echter Schmerz sein (wenn Sie jemals COM von C verwendet haben, wissen Sie, was ich meine).
Nebenbei, als Windows ursprünglich entworfen wurde, war C ++ auf PCs nicht so weit verbreitet und auch C wurde nicht so oft verwendet: tatsächlich war ein großer Teil von Windows 3.11 und viele Anwendungen immer noch in Assembly geschrieben, da die Speicher- und CPU-Einschränkungen in der Ära sehr eng waren; Compiler waren auch weniger intelligent als jetzt, vor allem C ++. Auf Maschinen, bei denen die handgeschmiedete Montage oft die einzige Lösung war, war der C ++ Overhead wirklich inakzeptabel.
Die Pointers-Sache: Windows-APIs verwenden fast immer Handles , dh undurchsichtige Zeiger, um die zugrunde liegende Natur jeder Ressource zu ändern, ohne die bestehenden Anwendungen zu beeinflussen und Anwendungen daran zu hindern interne Strukturen. Es spielt keine Rolle, ob die Struktur, die der Fenstermanager verwendet, um ein Fenster intern darzustellen, geändert wird: Alle Anwendungen verwenden einfach ein HWND, das immer die Größe eines Zeigers hat. Sie können dies als eine Art von PIMPL Idiom denken.
Windows ist jedoch in gewisser Weise objektorientiert (siehe zum Beispiel das ganze "Fensterklassen" -Konzept oder, auf einer tieferen Ebene, das innere Arbeiten des NT-Kerns, das stark auf dem "Objekt" -Konzept basiert ), aber seine einfachsten APIs, einfache C-Funktionen, verstecken diese OO-Natur irgendwie. Die Shell, auf der anderen Seite, die viele Jahre später entworfen wurde, ist hauptsächlich in C ++ geschrieben und bietet eine wirklich objektorientierte COM-Schnittstelle.
Interessanterweise können Sie in COM alle Kompromisse sehen, denen Sie bei der Erstellung einer sprachübergreifenden, aber C ++ - orientierten objektorientierten Schnittstelle gegenüberstehen: Das Ergebnis ist ziemlich kompliziert, in mancher Hinsicht hässlich und nicht wirklich einfach zu verwenden Sprache. Die Windows-APIs hingegen, die einfache Funktionen sind, sind in der Regel leichter aufrufbar.
Wenn Sie an einem System interessiert sind, das auf C ++ - APIs basiert, können Sie sich Haiku ansehen ; Das ist einer der Aspekte, an denen ich mich sehr interessiert.
Übrigens, wenn Sie Win32-Programmierung nur mit den APIs machen, sollten Sie sich ein gutes Buch besorgen, um sich an diese "Besonderheiten" und an andere Win32-Idiome zu gewöhnen. Zwei bekannte sind die Rector-Newcomer und die Petzhold .
Weil Win32 Api auf C geschrieben wird, nicht in C ++. So kann jedes Programm in fast jeder Sprache diese API aufrufen.
Außerdem gibt es keinen einfachen Mechanismus, um Objekte in verschiedenen Modulen und verschiedenen Sprachen zu verwenden. I.e. Sie können die C ++ - Klasse nicht in Python exportieren. Natürlich gibt es Techniken wie OLE / COM, aber sie sind immer noch auf Ebene C geschrieben. Und sie sind etwas kompliziert zu benutzen.
Auf der anderen Seite - Anrufe zu normalen C-Funktionen sind standardisiert. So können Sie Routinen von DLL oder statischer Bibliothek in jeder Sprache aufrufen.
Win32 wurde entwickelt, um mit der C-Sprache und nicht mit C ++ zu arbeiten.
Deshalb sehen Sie beispielsweise die Rückgabetypen des definierten BOOL anstelle von bool .
bool ist spezifisch für C ++ und existiert nicht in C.
Für Microsofts objektorientierte Wrapper von Win32 siehe MFC .
Ein neueres Framework von Microsoft seither ist das .Net Framework.
Das .NET-Framework basiert jedoch auf verwaltetem Code und wird nicht nativ ausgeführt. Die modernste Art, GUI unter Windows zu programmieren, ist WPF oder sogar Silverlight.
Die modernste Art, nicht verwaltete GUI-Programmierung zu machen, verwendet immer noch MFC, obwohl einige Leute immer noch lieber direktes Win32 verwenden.
Hinweis: Das Arbeiten mit Zeigern ist nicht spezifisch für C, in C ++ ist es immer noch sehr üblich.
Der erste Grund ist, weil die Weitergabe von Zeigern billig ist. Zeiger sind 4 Bytes auf x86 und 8 Bytes auf x64. Während die Struktur oder Klasse, auf die es zeigt, viel mehr Speicher belegen kann. Eine Instanz instanziieren bedeutet, immer wieder neuen Speicher zu reservieren. Dies ist nicht effizient bei Geschwindigkeits- und Speicherverbrauchs-POVs.
Eine andere Möglichkeit besteht darin, Referenzen auf Objekte oder intelligente Zeiger oder ähnliche Konstrukte zu übergeben. Aber win32 api wurde in der C-Ära entworfen, also ist es das, wo es bis jetzt ist;)
Wie wäre es mit einem potenziellen Durcheinander mit Zeigern - das ist natürlich möglich. Aber die meiste Zeit ist ihre Lebensdauer explizit in der API angegeben (wenn nicht offensichtlich).
Die Windows-API ist ein einfaches altes C, daher die Verwendung von Zeigern überall. Der Grund, warum Sie Windows nach einem neuen Zeiger fragen, ist, dass Windows alle Objekte verfolgen muss ... es weist Dinge zu und sagt Ihnen einen Zeiger (oder manchmal nur eine numerische ID), damit Sie mit ihnen arbeiten können.
Alle HWND, HANDLE, HDC sind nur ein schwacher Versuch, geklammerte, objektartige Datentypen zu machen (mit struct ). C FAQ hat eine Frage zu diesem - & gt; Zypern .
Um die Hinweise zu verstehen, sollten Sie das CPlusPlus.com-Lernprogramm für Zeiger lesen.
>