Was bringt einem C++ noch?

[malo]

Überall sieht man sie: Die C++ler. Viele Leute programmieren C++, viele (aktuelle) Programme werden in C++ geschrieben. Erst neulich hab ich in "Herr der Ringe - Schlacht um Mittelerde" eine Visual C++ Exception ausgelöst. Nur, was ist so toll an C++?

Zitat:

Zitat von www.galileocomputing.de

In Kombination mit der .NET Common Language Runtime kann diese Sprache [C#] für die Entwicklung komponentenorientierter Software eingesetzt werden, ohne dass die Programmierer ihr Potenzial im Hinblick auf C-, C++- oder COM-Code ungenutzt lassen müssen.

C# wurde für die Entwicklung robuster, langlebiger Komponenten konzipiert, mit denen Situationen des wirklichen Lebens bewältigt werden können.

C# ist ja dann scheinbar die ".NET-Version" von C++. Warum lernt man dann nicht einfach auf C# um, das ja soviel robuster als C++ ist? Die Syntax ist ja bei C++ und C# soweit gleich, da fällt der Umstieg ja relativ leicht. Außerdem wird ja auch noch an Visual C++ weiterentwickelt, nur warum sollte man denn eine uralte Sprache (c++) am Leben halten, wenn ein Nachfolger (C#) bereits existiert (bzw. eine "erweiterte Form" der alten Sprache)? Oder hab ich da was falsch verstanden?

Oder hat C++ noch irgendwelche grundlegenden Vorteile gegenüber C#? Lohnt es sich eventuell sogar noch, C++ zu lernen?



Wenn ich irgendwo Mist erzählt haben sollte, bitte nicht hauen. Ich hab alles nur so geschildert, wie ich es verstanden hab ;)

[tommie-lie]

Zitat:

Zitat von malo

Oder hat C++ noch irgendwelche grundlegenden Vorteile gegenüber C#?

Nativer Code, Ausgereiftheit und ausgereifte, etablierte Bibliotheken für alles und jeden.

[CalganX]

Hi,
C# ist nicht direkt die .NET-Version von C++. Das wäre Managed C++, was aber kaum jemand verwendet, aus den von dir genannten Gründen.
Der wesentliche Unterschied ist halt, dass C# .NET ist und C++ Win32. Denn mit C# kannst du kein Spiel programmieren, das wäre viel zu langsam, weil .NET einfach nicht für DirectX/OpenGL ausgelegt ist und somit nicht die nötige Performance aufbringen kann. Und wenn man das schaffen würde, wäre das ein erheblich hoher Ressourcenverbrauch. Also verwendet man C++, weil dass die Sprache ist, die von Microsoft gewählt wurde, um Dinge wie DirectX oder OpenGL zu entwickeln. Das "Schöne" daran ist, dass es sowohl auf UNIX-Basis als auch auf Windows-Basis läuft, da beide Betriebssysteme mit C entwickelt wurden und C++ eigentlich nichts Anderes, als die Weiterentwicklung von Ersterem ist.
Und eine Übersetzung der Bibliotheken wäre zu unsicher, zu teuer und zu zeitaufwändig. Also einfach das nehmen, was da ist. Denn C++ ist eigentlich die Programmiersprache gewesen, mit der alle Welt programmiert. Selbst Delphi kann keine Konkurrenz mit C++ aufnehmen. Zumindest in seiner ursprünglichen Form, da Delphi für die Datenbank-Entwicklung geschaffen wurde und somit versucht ein ganz anderes Feld abzudecken. Außerdem ist Delphi für OOP ausgelegt und mit C++ ist das relativ schlecht möglich. Das ist zwar ein großer Vorteil, dennoch ist die Entwicklung von aufwändigen Grafik-Anwendung nicht sehr verbreitet, weil Delphi einfach nicht die nötige Performance bringen kann, die C++ bringt.

Soweit von dem, was ich in den Tiefen meines Hirnes finden konnte. Ich bin mir aber nicht zu 100% sicher, ob das alles schlüssig und vorallem richtig ist. Lasse mich gerne korrigieren. :)

Chris

[mr47]

Ja kann man denn mit C ++/# irgendwas machen, was man mit Delphi (bzw. Object Pascal) nicht kann?

[Robert_G]

Zitat:

Zitat von mr47

Ja kann man denn mit C ++/# irgendwas machen, was man mit Delphi (bzw. Object Pascal) nicht kann?

C++ kann Mehrfachvererbung. C++ kann man zu allen möglichen Plattformen kompilieren.
Es gibt eine ganze Reihe von "perversen Features" in C++, die es (zum Glück) nie zu Delphi oder C# geschafft haben.

Mehrfachvererbung hätte der CLR schon ganz gut gestanden, aber es geht ja auch mit Interfaces... :?

Delphi32 und C# zu vergleichen wäre unfair, da C# eine .Net-Sprache ist und man somit auf Tausende Basisklassen der FCL zurückgreifen kann.

Wenn du jetzt fragen würdest was man mit C# machen kann, dass Delphi.Net nicht kann:
Mit C# kann man wunderbar .Net programmieren. Mit Delphi.Net kann man versuchen .Net zu programmieren. :P

Zitat:

Zitat von Chakotay1308

Der wesentliche Unterschied ist halt, dass C# .NET ist und C++ Win32. Denn mit C# kannst du kein Spiel programmieren, das wäre viel zu langsam, weil .NET einfach nicht für DirectX/OpenGL ausgelegt ist und somit nicht die nötige Performance aufbringen kann. Und wenn man das schaffen würde, wäre das ein erheblich hoher Ressourcenverbrauch.

Das ist Käse. Es gibt zum Beispiel Managed DirectX. Das ist eine komplette Portierung von DirectX, die in C# geschrieben wurde.
Auf die Art kann man DirectX verwenden OHNE .Net verlassen zu müssen.
Das ganze verliert etwa 1-2% der Performance gegenüber hochoptimierten DX-Zugriffen aus nativem C++.

Es gibt aber immer noch "krasse Chegga", die aus irgendeinem masochistischem Trieb lieber OpenGL in C# benutzen. :mrgreen:

[Phoenix]

Mit C++ ja. Zum Beispiel Treiber programmieren. Das ist in Delphi ein nahezu unmögliches Unterfangen. Aber C# steht da genauso schlecht da.

@Chakotay: Das mit den Spielen ist eine glatte Lüge.
Quake II wurde komplett nach managed C++ portiert und läuft ohne Performance-Einbussen 100% auf .NET: Quake II .NET.

Soviel zum Thema .NET sei langsam.

[Robert_G]

Zitat:

Zitat von Phoenix

@Chakotay: Das mit den Spielen ist eine glatte Lüge.
Quake II wurde komplett nach managed C++ portiert und läuft ohne Performance-Einbussen 100% auf .NET: Quake II .NET.

Es ist einen Tick langsamer, da sie das originale Memorymanagement nicht entfernt haben. Auf die Art konkuriert die Instanzverwaltung des Spiels mit der Garbage Collection. (Ist aber nur minimal langsamer ;) )

Zitat:

Zitat von Phoenix

Soviel zum Thema .NET sei langsam.

Das könnte ich so auch nie stehen lassen. Fast jeder wohlüberlegte Code dürfte in .Net mindestens gleichschnell sein. Aufgrund des genialen JIT ist vielles schneller. Multithreading ist zum Beispiel massiv schneller, da man 90% aller Synchronisierungen umgehen kann.

[malo]

Also heißt das, C++ ist für alles überflüssig, außer für direkte Systemeingriffe (z.B. Treiber) und für DirectX / OpenGL-Programme, die nicht auf 1-2% Performence verzichten können? Und warum wird immer noch soviel in C++ gemacht? :gruebel:

Weil es kommt mir vor, als sei C# für alles andere einfach besser geeignet als C++ :gruebel:

[Tubos]

Ich für meinen Teil programmiere deshalb in C++ und nicht in C#, weil ich im Moment noch mit Win32 arbeite. Wenn ich dann auf .NET umsteigen, wird C# drankommen.

[rgernha]

Zitat:

Zitat von malo

Also heißt das, C++ ist für alles überflüssig, außer für direkte Systemeingriffe (z.B. Treiber) und für DirectX / OpenGL-Programme, die nicht auf 1-2% Performence verzichten können? Und warum wird immer noch soviel in C++ gemacht? :gruebel:

Weil es kommt mir vor, als sei C# für alles andere einfach besser geeignet als C++ :gruebel:

Das noch soviel in C++ gemacht wird hat sicher viele Gründe:
z.B. sind viele bestehende Systeme / Prorgamme in C++ geschrieben und nicht jede Firma hat das Geld alle neu zu codieren.
Außerdem haben viele Entwickler C++ müsahm gelernet und es gibt für sie eigentlich keinen Grund eine andere Sprache zu benutzen , da C++ sogut wie alles kann.
Eine viel berechtigtere Frage wäre , wer braucht Delphi , wenn es C++(oder C# für Delphi.net) gibt?
Außerdem kann nicht jeder das .net Framework benutzen (z.b. unter Linux auch wenn es Mono gibt).

Ein anderer Grund ist, dass C++ die eine Sprache für kleine Geräte ist. Z.B. der Ti89 lässt sich mit C programmieren.

Sowieso werden Betriebssysteme usw. in C/C++ geschrieben (und natürlich assembler :-) ).

Aber die C++ werden wohl doch zurückgehen, weil viel, wofür früher C++ mit z.B. den MFC genutzt wird, wird in naher Zukunft wohl mehr auf .net gesetzt.

So klein ist der Perfomance Unterschied zwischen C/C++ und C# gar nicht, wenn man sich mal Benchmarks ansieht.

Man kann aber durchaus Spiele in C# schreiben , siehe Arena Wars.(http://www.gameports.net/gp/artikel_1598.html)