Gründe für die Verwendung von nativem C++ mit Windows API

Moin,

ich möchte nicht trollen, auch wenn die folgende Frage etwas provokant wirkt:
Welche Argumente gibt es, heute noch für Windows mit nativem C++ (und der Windows-API) zu programmieren, wenn man mal von plattformunabhängigen Programmen absieht, welche die Windows-API lediglich benutzen, um das Verhalten auf anderen Betriebssystemen nachzustellen?

In Zeiten von .Net Framework lassen sich viele Programme mit den entsprechenden Sprachen viel einfacher, schneller (hinsichtlich Programmieraufwand) und übersichtlicher (meine subjektive Meinung). Gäbe es andere Gründe, trotzdem auf natives C++ (mit Windows API) zurückzugreifen? Performance?

MfG
KeinTroll

Jop, Performance trifft es. Zwar ist .NET, was mathematische Berechnungen zumindest angeht, ziemlich fix aber letztendlich ist es für das meiste doch nur ein Wrapper um die Windows API. Ich mag .NET und arbeite zu 90% während meiner Arbeitszeit damit aber eben die letzten 10% haben es dann in sich.

Wofür verwende ich die Windows API in Kombination mit C/C++:
-Für unsere Terminal Geräte mit Embedded Windows(GPS Kommunikationsmodul) die wenig Leistung und Kapazität haben
-Performanckritische Dinge wie Routenberechnung
-Terminalserver Anwendungen(dort kann ich einfach besser die Resourcen kontrollieren was ich in .NET leider nicht kann, dann wichtig, wenn sich zig Leute auf einem Terminal tummeln und der RAM knapp wird. Passiert schnell bei WPF)
-Windows Dienste schreibe ich, auch wenn es mit .NET sehr einfach ist, aus Gewohnheit immer in C

Mehr fällt mir so gerade nicht ein. Ich möchte es jedenfalls nicht missen

KeinTroll schrieb:

In Zeiten von .Net Framework lassen sich viele Programme mit den entsprechenden Sprachen viel einfacher, schneller (hinsichtlich Programmieraufwand) und übersichtlicher (meine subjektive Meinung). Gäbe es andere Gründe, trotzdem auf natives C++ (mit Windows API) zurückzugreifen? Performance?

Mit Qt und anderen Frameworks hat man beides: performanten C++ Code und eine tolle Klassenbibliothek die einem viel Arbeit abnimmt.
Und mit diesem Frameworks ist man dann auch auf anderen Plattformen startklar.

Mechanics

Die Frage ist mir schon zu umfangreich... Das sind eigentlich zwei Sachen, WinApi und C++. WinApi interessiert keinen und da geb ich dir recht, macht kaum Sinn, sie direkt zu benutzen. Es gibt gute Frameworks wie Qt oder GTK(mm), mit denen man GUIs viel bequemer erstellen kann. Ab und zu gibts paar Stellen, wo man selber eingreifen muss, dann hat man halt paar Zeilen, wo man direkt auf die WinApi zugreift.
Aber ein Programm sollte vor allem etwas machen und nicht die WinApi (oder irgendeine andere API) benutzen. Und ob man die Logik in C++ oder einer anderen Sprache implementiert ist eine ganz andere Frage. Ich habe jahrelang C# programmiert und finde die Sprache und das Framework sehr elegant und bequem. Aber es ist jetzt nicht unbedingt wesentlich produktiver, als C++. Bei großen Projekten relativiert sich der Vorteil von C# sehr schnell. Und mit C++ ist man vielleicht etwas flexibler. Jetzt arbeite ich schon seit Jahren als C++ Entwickler an einem sehr großen Projekt und vermisse .NET nicht wirklich. Ich glaube nicht, dass wir damit produktiver wären.

und hier reduziert man WinAPI mit C++ auf GUIs. ja, mit .NET oder anderen ähnlichen umgebungen kann man schnell und leicht GUIs erstellen. aber die WinAPI hat eben noch weit mehr funktionalität als bloß GUIs zu erstellen. systemnahe anwendungen würde ich nicht versuchen in .NET zu schreiben, sofern es mit .NET nicht möglich ist und es nativ über C oder C++ einfacher und schneller (im sinne von performantem code) geht.

KeinTroll schrieb:

Welche Argumente gibt es, heute noch für Windows mit nativem C++ (und der Windows-API) zu programmieren

KeinTroll schrieb:

In Zeiten von .Net Framework lassen sich viele Programme mit den entsprechenden Sprachen viel einfacher, schneller (hinsichtlich Programmieraufwand) und übersichtlicher (meine subjektive Meinung). Gäbe es andere Gründe, trotzdem auf natives C++ (mit Windows API) zurückzugreifen? Performance?

übrigens sollte man hier sehen, dass der fragesteller keinen expliziten bezug auf GUI programmierung stellt, bewusst oder unbewusst.
.NET ist mehr als nur das reine GUI erstellen. man kann übrigens auch module und consolenanwendungen erstellen.
die fragestellung ist leider allgemein gehalten.

Mechanics schrieb:

Aber ein Programm sollte vor allem etwas machen und nicht die WinApi (oder irgendeine andere API) benutzen.

Ja, und damit es etwas "machen" kann, muss eine API her. Oder wie willst du den usermode programmen erlauben gewisse aktionen durchzuführen, wie z.b. dateien auf einer festplatte lesen oder speicher aus einem remote process lesen? software interrupts sind eben im protected mode nur für programme erlaubt die im kernelmode laufen und auch kann man nicht einfach unter Windows im usermode ohne die WinAPI den speicher eines anderen prozesses auslesen. ein Windows-Programm im usermode kommt eben ohne API nicht aus.

übrigens sollte man eine programmiersprache primär erst anhand der anforderungen der zu erstellenden software auswählen und erst dann nach geschmack (sofern mehr als 1 sprache übrigbleibt).