?
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).