Ich beende meinen Sommerjob, in dem ich grafische Software für unsere Gepäckscanner schreibe. Alles wird in .NET oder MFC gemacht, mit reinem C ++ für Hardware-Kommunikation (ich mache keine Hardware-Sachen). Ich habe manchmal auf Win32-API-Aufrufe wie SendMessage zurückgegriffen, um die Leistung eines Formulars oder Steuerelements zu verbessern. Ich hatte nur ein Jahr lang CS-Kurse (alles in C), aber ich bin fasziniert von der Win32-API - sie ist viel größer und mächtiger als ich dachte.
Verdeckt .NET einfach all die "langweiligen" oder Boden-Level-Arbeiten der Win32-API? Nimmt die endgültige Software mehr Systemressourcen auf oder wird sie in .NET langsamer ausgeführt?
.Net macht im Allgemeinen die Entwicklung einfacher. Dies geschieht durch Bereitstellung eines Systems, das die gemeinsamen Aktivitäten weniger Aufwand für den Entwickler erfordert.
Ich liebe es in .NET zu arbeiten. Bevor es verfügbar wurde, arbeitete ich hauptsächlich an einer GUI, die in C ++ mit MFC und Win32 geschrieben wurde. Als ich zu .NET wechselte, musste ich meine Schätzungen komplett überarbeiten, weil ich die Dinge schneller erledigen konnte!
Um Ihre tatsächlichen Fragen zu beantworten: Es gibt weniger häufige Entwicklungsszenarien, in denen .NET nicht hilft (und manche sagen, dass es in die Quere kommt). Diese beinhalten im Allgemeinen Low-Level-Nutzung der Hardware-Kommunikation oder fein abgestimmte COM-Programmierung.
Beachten Sie, dass Sie in C ++ für .NET entwickeln können, so dass Sie mit wenig oder gar keinem Aufwand zwischen Win32 und .NET wechseln können. (Es ist kein Standard-C ++, wenn Sie zur CLR entwickeln, aber es ist auch nicht schwierig, die Unterschiede zu erkennen.)
Betrachten Sie keine Leistung ohne ein tatsächliches Szenario, das Sie tatsächlich testen können. Für einen interessanten Leistungsvergleich von .NET und C ++ auf der gleichen Aufgabe, schauen Sie sich den Blog-Eintrag (und Links!) Hier an: Ссылка
Verdeckt .NET einfach all die "langweiligen" oder Boden-Level-Arbeiten der Win32-API? Nimmt die endgültige Software mehr Systemressourcen auf oder wird sie in .NET langsamer ausgeführt?
Ja, es versucht alle langweiligen Details zu verbergen. Und ja, eine .NET-Anwendung wird im Allgemeinen langsamer sein und wahrscheinlich mehr Ressourcen verbrauchen als eine ähnliche Anwendung in C und Win32.
Aber die Leistungseinbußen sind normalerweise ein vernachlässigbarer Preis für die Produktivitätssteigerung und die einfache Wartbarkeit.
Ich verstehe, dass der Faktor der Programmierung so nah am blanken Metall mit einfachem C und reinem win32 sehr verlockend aussieht, aber ich finde es schwer zu rechtfertigen, wenn es viel einfacher und schneller wäre, .NET zu verwenden .
Der Vorteil von .NET ist, dass es eine produktivere Entwicklungsplattform ist. Viele Teile des .NET-Frameworks bieten einen partiellen Wrapper von Win32-APIs. Obwohl das Framework tatsächlich viele "langweilige" Win32-API-Aufrufe abstrahiert, hindert mich das nicht daran, von Zeit zu Zeit ein kleines PInvoke zu benötigen.
Sie werden feststellen, dass das .NET-Framework einen geringen Aufwand erfordert und nicht so effizient ist wie C oder C ++. Häufig besteht jedoch der Kompromiss zwischen Produktivität und Effizienz. Die Anforderungen der einzelnen Anwendung bestimmen, was wichtiger ist. In einer Vielzahl von Software müssen die Anforderungen "effizient genug" sein und möglicherweise vollständig für die .NET-Entwicklung geeignet sein.
Die einfache Antwort auf Ihre Fragen sind "Nein", "Ja" und "Nicht unbedingt", in dieser Reihenfolge. Das heißt, dass .NET die Win32-API viel mehr als nur "versteckt", es in einigen Fällen umschließt, in anderen erweitert und in anderen Fällen vollständig ignoriert.
Software, die mit dem .NET-Framework entwickelt wurde, wird oft mehr Ressourcen verbrauchen als die schlanke handcodierte Assembly, die (theoretisch) von einem Experten erstellt werden könnte. In vielen Fällen verwendet der C- oder C ++ - Entwickler Frameworks und Toolkits, die genauso schwer sind wie das .NET-Framework, und der Unterschied wird ein Wash sein. Die andere Sache, die man beachten sollte, ist, dass es normalerweise keine Rolle spielt, ob ein Programm heutzutage ein paar zusätzliche kb Speicher verbraucht. Niemand bemerkt es. Wenn die Vorteile der Entwicklung in .NET (oder einer anderen Technologie) die Risiken überwiegen, dann ist es eine bessere Wahl. Nur du kannst das für deine spezielle Situation sagen.
Was "Performance" angeht, ist das eine ziemlich große Kategorie, aber da .NET-Code in Maschinensprache kompiliert wird (es wird nicht interpretiert), gibt es im Allgemeinen wenig Unterschiede. Auch hier wird der Programmer für die Hard-Code-Assemblierung wahrscheinlich besser sein, aber wenden Sie Ihre Kosten-Nutzen-Analyse an, um festzustellen, ob es sich für Sie lohnt.
Alles, was Sie erwähnt haben, ist auf Win32 "geschichtet", ja. Win32 ist eine der niedrigsten Ebenen, mit denen Sie programmatisch in Windows arbeiten können. Meiner Meinung nach ist es äußerst vorteilhaft, Win32 zu lernen.
So ziemlich alles basiert darauf. (Das und COM.) Es ist, als würde man lernen, wie Register auf einer CPU funktionieren, anstatt eine Black-Box zu sein.
All die wirklich guten (professionellen) Windows-Programmierer, die ich kenne, kenne sie und kenne sie gut.
Programmierfenster von Charles Petzold ist so ziemlich die Bibel für Win32 und IMO, ist gut -geschrieben und ausgeführt.
Übrigens, ich denke jeder, der ein "Ingenieur in ihrem Herzen" ist, muss genauso wie in ihrem Kopf immer wissen, wie die Dinge funktionieren. Ich denke, es ist eine gute Sache.
.NET ist beabsichtigt , die langweiligen Details der Win32-API zu verbergen. Das gelingt in mancher Hinsicht, bei anderen jedoch. Wenn das meiste von dem, was Sie schreiben, gut zu dem passt, was MS zu unterstützen versucht, kann es durchaus gelingen. Wenn Sie in "Neuland" aufbrechen, können Sie den Vorteil vollständig verlieren und sogar eine Menge zusätzlicher Arbeit im Vergleich zu nativem Code, der Win32 direkt verwendet, verursachen.
Die resultierende Software (im Wesentlichen immer) verbraucht mehr Ressourcen als nativer Code. Die einzige wirkliche Frage ist, wie viel mehr Speicher verwendet wird, wie viel langsamer läuft usw.
Diese sind leider schwer zu beantworten. Geschwindigkeit kann irgendwo von im Wesentlichen identisch mit 8x langsamer oder so sein. Die Speicherauslastung ist konsistent ein wenig höher (zB mindestens 2x, oft 3-5x). Ein interessanter Punkt ist, dass die Garbage-Collection einen Kompromiss zwischen Geschwindigkeit und Speicherverbrauch darstellt (das Ausführen des GC reduziert häufiger die Speicherauslastung auf Kosten von mit mehr CPU-Zeit. Daher hängt die Ausführungszeit genauso von der Speicherverfügbarkeit wie von der CPU-Geschwindigkeit ab.
Interessanterweise war eines der ersten Dinge, die ich persönlich mit .NET gemacht habe, das Portieren eines C ++ - Programms, von dem ich wusste, dass es ein Speicherleck hatte (ich wusste sogar, wo es war und ungefähr wie es zu beheben ist) tatsächlich wäre das eine Menge Arbeit gewesen). Die Portierung nach .NET dauerte nicht sehr lange (es gab nicht viel Code). Die gute Nachricht war, dass das Speicherleck verschwunden war. Die schlechte Nachricht war, dass der undichte C ++ - Code, so gut ich es beurteilen konnte, über ein Jahr ununterbrochen laufen musste, um so viel Speicher wie die .NET-Version zu verwenden, die nur zum Starten benötigt wurde.
Meine Antwort basiert auf einer Sache: C ++ ist ein ISO-Standard. C # ist eine proprietäre Microsoft-Sprache.
Wenn Sie jemals Ihre Fähigkeiten nach Windows erweitern möchten, iso C & amp; C ++ wird dich viel weiter sehen.
.NET hat ein großes Framework - aber wenn Sie wissen, wo Sie suchen müssen, gibt es einen riesigen Körper von lgpl und (wenn Sie damit kompatibel sind) gpl Open-Source-Software für C & amp; C ++. Boost wird zu einer riesigen Bibliothek, die die meisten von .NET angebotenen (Nicht-GUI-) Funktionen bietet, aber in einem plattformübergreifenden Standard.
Wenn es Ihnen nichts ausmacht, Ihre Seele zu verkaufen und Ihre Karriere dem anhaltenden Erfolg eines einzelnen Unternehmens zu verdanken, ... hat C # / .NET zwei große Boni, die das Win32-API nicht bietet:
>.NET lasst Sie schneller loslegen, wenn Sie lernen, insbesondere um Ihr Formular mit einer visuellen Oberfläche zu erstellen. Das ist eine Zeit lang sehr attraktiv, aber nach meiner Erfahrung finden Sie einige Einschränkungen.
Nachteile:
1 - Erfordert die entsprechende .NET-Framework-Version, die auf dem Clientcomputer vorhanden sein muss, was nicht immer garantiert ist.
2-Probleme mit 3D-Grafik-Anwendungen, nicht mehr unterstützte Unterstützung für .net directX. (SlimX-Engine funktioniert um das ich denke aber immer noch bist du irgendwie fest).
3 - Ihre 3D-Anwendung wird möglicherweise nicht mit neueren Versionen von Windows ohne Nacharbeit oder möglicherweise ohne Umgehung ausgeführt, siehe # 2. (Ich fand das auf die harte Tour)
Ich habe Win32 schon seit einiger Zeit studiert und obwohl es schwieriger ist, es zu starten, fühlt es sich stärker und schlanker an.
Nachteile:
1 - Sie müssen Header-Dateien in Ihrem Projekt bearbeiten, was für Anfänger etwas Zeit erfordert. Es gibt eine sehr spezifische Möglichkeit, mit diesen zu arbeiten, da der Compiler "One-Pass" ist und die Reihenfolge der Dinge wichtig ist.
2 - Die win32-API ist kritischer, mit allem, was in einem mehr oder weniger üblichen Namensraum ist, die große Liste ist mühsam zu erforschen.
3 - Es gibt keinen Hinweis / keine Beschreibung auf der Autocomplete-Anzeige der Mitglieder. Sie müssen also Wochen damit verbringen, die Dokumentation aller verschiedenen Mitglieder zu lesen.
4-Es gibt keine automatischen "Callbacks" wie in .NET (d. h. On_button_click), Sie müssen die Windows-Elemente über "Nachrichten" verarbeiten, die von den 'wnndproc' Funktionen behandelt werden. Dies dauert einige Zeit, um sich zu informieren, besonders wenn Sie von .NET kommen. Und wieder müssen Sie eine Menge Dokumentation durchforsten, um herauszufinden, welche Nachrichtennamen und Parameter Sie benötigen. Dieses Paradigma selbst ist kein Problem, aber es macht es schwierig, Ihre eigentliche Anwendung von Ihrem Windows-GUI-Design zu trennen.
5 - Da Windows-Elemente über 'Nachrichten' kommunizieren, erhalten Sie keine sinnvollen oder beschreibenden automatischen Vervollständigungsoptionen wie bei den eigentlichen Mitgliedsfunktionen ' Siehe diesen Pseudocode:
button.text="abc"; // In diesem Fall verstehen Sie die möglichen Optionen
vs
SendMessage (button_hwnd, BN_SETTEXT, "abc", 0); // muss MSDN / StackOverflow sehen
6 - Keine automatische Aufhebung der Zuweisung des Objektspeichers. Aber ich denke, das ist nicht so schlimm. Die C ++ - Klassen verfügen über eine Destructor-Funktion namens ~ name (), mit der Sie Objekte freigeben können, wenn die Instanz zerstört wird. Ich versuche auch, dynamische Arrays für Member zu verwenden, die zur Laufzeit instanziieren, dies hilft dabei, ordentlich zu sein und kümmert sich um die eigentlichen Zuweisungsprozeduren. Pseudocode:
Klassenspiel {
std :: vector (Geister-) Geister;
}
aktualisieren {
ghosts.pushback (); // füge eins, usw. hinzu
Ghosts.Erase (Position); // Jedes Element kann ausgeschaltet werden. das ist ziemlich gut
}
~ Spiel () {//
~ Geister (); // hebt die Zuordnung von Array auf
}
Was ich bisher gesehen habe, ist, dass Sie nur etwas achtsamer und strukturiert sein müssen, um Speicherlecks zu vermeiden, aber ansonsten würde ich die manuelle Freigabe nicht zulassen.
In Bezug auf die Übertragbarkeit würde ich argumentieren, wenn die Anwendung gut gekapselt ist, sollte es nicht zu schwierig sein, auf andere Plattformen zu portieren. Es lohnt sich nicht, sich auf das .NET-Framework zu verlassen, das ironischerweise die Portabilität selbst vernichtet. Aber jeder Kilometer variiert natürlich.
Aber ungeachtet der Nachteile bin ich bisher mit Win32 zufrieden, habe ungefähr zwei Monate investiert und meine eigenen Wrapper für die Windows-Steuerelemente erstellt, so dass es einfacher ist, mit den Fenstern zu arbeiten Formular programmgesteuert.
Ich führe auch die irllicht 3D-Engine auf dem Formular aus, und es scheint fehlerfrei auf mehreren Maschinen mit verschiedenen Windows-Versionen zu laufen. Es ist großartig zu sehen, dass die ausführbare Datei auf jedem (Windows-) Rechner ohne Abhängigkeiten oder Installationen läuft.
Programme laden schneller und scheinen kleiner zu sein. Aber in Bezug auf die Leistung, denke ich, gibt es heutzutage keinen großen Vorteil AFAIK.
Ich glaube, Microsoft hätte einfach ein paar einfache Wrapper für die API zusammen mit einigen netten Beispiel- und Vorlagenprojekten schreiben sollen, anstatt mit der ganzen sperrigen .NET-Route zu gehen.
Nur meine $ 0,02
Bearbeiten: Ich verstehe, dass MFC einige der Funktionen umschließt, aber ich habe gelesen, dass dies einen zusätzlichen Aufwand bedeutet, und es hat sich nicht wirklich durchgesetzt. Hoffe jemand könnte das hinzufügen, da ich nicht wirklich damit gespielt habe. Oh hier [ Lohnt es sich zu lernen Microsoft Foundation Classes (MFC) heutzutage?