C++ vs. C#

Jaa, das alte leidige Thema.
C++ oder C# ?
Indy oder Microsoft ?

Ich stelle mir diese Frage jetzt seit geraumer Zeit, und werde mir einfach nicht schlüssig. Einerseits ist C++ natürlich versiert, wobei der Gamehackingbereich mich besonders interessiert. Allerdings finde ich die GUI Programmierung in C++ extrem hässlich gestaltet, während es bei einem an Java angelehntem C# natürlich fast schon zu einfach ist.

Nun seid ihr gefragt: Was kann C++, was C# nicht kann ? Im Prinzip geht es ja nur darum.

Mit C# kannst du alles machen was in dem .NET Framework verfügbar ist dass du für dass Projekt ausgewählt hast, 4.0 ist momentan das aktuellste und sehr umfangreich. Die Sache mit dem Gamehacking ist so eine Sache mit C#, es ist möglich. Direct X Hooks sind mit den richtigen Klassen kein Problem und Bots sind eben falls realisierbar. C / C++ sind dafür aber schneller, solltest du also Dinge programmieren wollen bei denen es auf Geschwindigkeit ankommt solltest du zu C / C++ greifen (Da du aber wohl kaum Steuerungsanlagen für Atomkraftwerke programmierst dürfte dass nicht so gravierend sein ;)). Und solltest du auf etwas stoßen dass in C# zu umständlich ist kannst du eine in C++ geschriebene .dll ohne weiteres in dein Programm einbinden.

c++ kann injizierbare dlls erstellen, kann inline asm verarbeiten, ist systemnahe, was will man mehr für gamehacking ?

c# ist nunmal .net. Es wird zur laufzeit kompiliert, ist also viel langsamer. der quellcode ist für jeden mehr oder weniger einsehbar und die Windows API muss erst importiert werden.

Quote:

Und solltest du auf etwas stoßen dass in C# zu umständlich ist kannst du eine in C++ geschriebene .dll ohne weiteres in dein Programm einbinden.

das ist wohl wahr, geht aber genau so gut in fast allen anderen sprachen auch:
delphi, autoit, sogar in python.

Auch für c++ gibt es IDEs, die Benutzeroberflächen erstellen können.
Allerdings muss man wohl zugeben, dass c#, generell .net und java, nicht so komplex ist wie das schon ältere c++.

Nunja, soweit weiterhin die geteilte Meinung.

Wie sieht es denn mit Memoryreading/-writing in C# aus ? Sachen wie memcpy, ReadProcessMemory, WriteProcessMemory. Soweit realisierbar vergleichsweise mit C++ ?

Die WinApi kannste eh nutzen.
C# unterstützt noch ein paar nette Funktionen für Memory Writing, aber generell gilt natürlich, dass es mit C++ simpler geht, da die Sprache nativ ist und direkten Zugriff auf den Speicher hat.

Für C# gibts doch das unmanaged keyword oder so, wo man nativ arbeiten kann, weiß dazu nix genaueres.

Aber Detouring und Code Patching ist vor allem dank inline asm definitiv leichter in C++

Die Frage "C# vs. C++" ist insofern überflüssig, als das beide Sprachen gleichberechtigt sind. In den Fällen, in denen es sinnvoller ist das .NET Framework zu nutzen, z.B. GUI - Anwendung, die nur auf Windows laufen soll, dann nimmst du eben C#.
Willst du etwas schreiben, das vom Quellcode plattformunabhängig sein soll, oder es auserordentlich wichtig ist, dass das Programm schnell abgearbeitet wird, dann nehm C++.
Willst du echte Plattformunabhängigkeit, dann nehm Java.

Fazit: Als Programmierer ist es sehr, sehr, sehr, sehr sinnvoll möglichst vierschiedene Sprachen zu können. Dir hilft es zum Beispiel nicht viel, wenn du C# und VB.NET kannst. Daraus ziehst du keinen Vorteil. Beherrscht du aber C#, Java, C++, dann ist das sehr von Vorteil. Denn dann kannst du die Sprache verwenden, die für deine Zwecke am sinnvollsten ist.
Also: Beides gleich gut, kommt nur auf dein Ziel an.

Ich muss mich meinen Vorpostern auch anschließen. C# ist für GUI Anwendungen geeignet, c++ eher nicht so.

Ich habe damals selber mit vb.net angefangen. Später kam dann noch c# dazu, dass zu lernen ging aber auch sehr schnell. Nach c# habe ich dann mit C++ angefangen. Später dann ja auch noch java.

Insgesammt sage ich, dass du möglichst beide Sprachen lernen solltest. Ich würde selber mit C# anfangen. Ich fand damals C# leichter zu lernen, aber das hängt vom Betrachter ab. DAs hilft auch beim C++ lernen. Beherrschst du eine Programmiersprache, ist es leichter für dich eine neue zu lernen.

Ich höre immer das Argument C++ wäre für Dinge geeignet, die besonders schnell von statten gehen müssten. Für welche Dinge im täglichen Gebrauch zählt das denn ?

Quote:

Originally Posted by Drake^ Ich höre immer das Argument C++ wäre für Dinge geeignet, die besonders schnell von statten gehen müssten. Für welche Dinge im täglichen Gebrauch zählt das denn ?

Eventuell solltest du dann auch weiterlesen, es wurde gesagt, wenn es nicht gerade um Steuerungsanlagen für Atomkraftwerke geht, kann man diesen Punkt ignorieren, da es kaum Einfluss auf Privatanwender hat.
Du kannst allerdings nicht bestreiten, dass Bytecode langsamer als nativer Code ist und bei manchen Spielen, gerade die, bei denen sogar inline asm zur Optimierung genutzt wird, macht das C++ auch mal zur Sprache der Wahl.

Quote:

Ich höre immer das Argument C++ wäre für Dinge geeignet, die besonders schnell von statten gehen müssten. Für welche Dinge im täglichen Gebrauch zählt das denn ?

Kommt drauf an was du für Anforderungen an dein Programm stellst.
Einen Server der z.b.: Spielerdaten zu berechnen hat würde ich zu den Zeitkritischen Dingen zählen.
Ein Programm was Grafiken manipuliert und dazu Algorithmen nutzt sollte auch auch in einer Sprache geschrieben sein in der solche Berechnungen schnell von statten gehen, denn es gibt nix nervigeres als Stunden lang zu warten bis dein Renderer endlich mal das Bild ausspuckt.

Klar kann man zu einem gewissen Grad solche Routinen optimieren, nur irgendwann ist Schluss :)

Direkte Beispiele für den privaten Gebrauch sind: Bildbearbeitungsprogramme, Renderer, VST-Instrumente und Spiele.
Demos so wie sie auf der Breakpoint zu sehen waren sind auch solche Dinge.

Etwas OT, aber dennoch ein nettes Beispiel was passiert, wenn man sich zu viel Zeit mit der Ausführung lässt:
Früher waren die Demos und Programme auf de C64 die sehr schnell ausgeführt werden mussten in ASM geschrieben und sehr optimiert, was bis zur Ausnutzung illegaler Opcodes ging.
Ein sehr nettes Beispiel ist hier die Musik-DudelRoutine im IRQ bei $1000.
Kombinierte man sie mit einer Rasterbar musste man hier sehr genau aufpassen wie schnell alles ausgeführt wird.
Machte man einen Fehler sah man keine Rasterbar (ein mehrfarbiger Balken, der durch geschickte Manipulation der Hintergrundfarbe erzeugt wurde), sondern nur das Flimmern der Hintergrundfarbe.