C# scheint ein paar Vorteile zu C++ zu haben? Speichermanagement etc. habe ich öfters gehört.

Messer scheinen auch ein paar Vorteile gegenüber Löffeln zu haben. Schärfe zum Beispiel.

Wird C++ irgendwann aufholen, rsp. C# keine Vorteile mehr bieten?

Nein. Genausowenig wie Löffel jemals so scharf wie Messer werden. Dafür wird man mit Messern nie so gut Suppe löffeln können...

Gibt es irgendwo eine Roadmap für C++ oder sowas? Wer hat denn C++ 11 gemacht?

Der C++-Standard wird vom Standardkommitee entwickelt. Das ist ein Internationales Kommitee, dem Vertreter der verschiedenen nationalen Standardisierungsorganisationen angehören (für Deutschland könnte z.B. das DIN jemanden entsenden). Hauptsächlich handelt es sich dabei um Vertreter der Industrie, in dem Fall z.B. der größeren Compilerhersteller.

Was ich mit den Messern und Löffeln sagen will: C# und C++ sind zwei unterschiedliche Sprachen, die in verschiedenen Bereichen Stärken und Schwächen haben. Keine von beiden wird versuchen, der anderen in ihren besonderen Stärken den Rang abzulaufen, weil sie dafür einfach nicht entworfen wurden.

Gibt es irgendwo eine Roadmap für C++ oder sowas? Wer hat denn C++ 11 gemacht?

Der C++-Standard wird vom Standardkommitee entwickelt. Das ist ein Internationales Kommitee, dem Vertreter der verschiedenen nationalen Standardisierungsorganisationen angehören (für Deutschland könnte z.B. das DIN jemanden entsenden). Hauptsächlich handelt es sich dabei um Vertreter der Industrie, in dem Fall z.B. der größeren Compilerhersteller.

Mit "verschiedenen nationalen Standardisierungsorganisationen" hat das soweit ich weiss nix zu tun. Würde mich auch wundern wenn da auch nur ein Mitarbeiter der DIN/ISO/ANSI/... drinnen sitzen würde.

Da sitzen einfach Freiwillige drinnen. Wer entscheidet wer aufgenommen wird und wer nicht weiss ich nicht - vermutlich einfach das aktuelle Kommitee. Glaube aber nicht dass es da irgendwas gibt wo geregelt wäre wer ein "Anrecht" auf Mitgliedschaft hat oder ähnliches.

Was ich mit den Messern und Löffeln sagen will: C# und C++ sind zwei unterschiedliche Sprachen, die in verschiedenen Bereichen Stärken und Schwächen haben. Keine von beiden wird versuchen, der anderen in ihren besonderen Stärken den Rang abzulaufen, weil sie dafür einfach nicht entworfen wurden.

Eine grosse Schwäche von C++ ist, dass die Standard-Library ultra-mini-klein ist (verglichen mit der von Java oder C#). Und diesen Nachteil will das C++ Standard-Kommitee schon ausräumen. Ist nur unrealistisch dass sich in absehbarer Zeit genug tut so dass C++ in dieser Hinsicht wirklich mit Java oder C# mithalten könnte.

Mit "verschiedenen nationalen Standardisierungsorganisationen" hat das soweit ich weiss nix zu tun. Würde mich auch wundern wenn da auch nur ein Mitarbeiter der DIN/ISO/ANSI/... drinnen sitzen würde.

Da sitzen einfach Freiwillige drinnen. Wer entscheidet wer aufgenommen wird und wer nicht weiss ich nicht - vermutlich einfach das aktuelle Kommitee. Glaube aber nicht dass es da irgendwas gibt wo geregelt wäre wer ein "Anrecht" auf Mitgliedschaft hat oder ähnliches.

Ich hatte mich dahingehend mal umgeschaut, rein aus Interesse was man machen muss um sich so eine Sitzung anzusehen. Du musst Mitglied eines "National Body" der ISO sein. Und die National Bodies sind nunmal die Institute wie ANSI, DIN, BSI usw. Du kannst nicht einfach hingehn und sagen "Hi ich bin Otto, darf ich mitspielen?"

ps: Vielleicht muss man Mitglieg des "national body der ISO" sein wenn man sich das ganze quasi ohne "Einladung" ansehen will... das könnte schon sein.

C, C++ und ObjC sind daher effizienter, da sie diesen Umweg nicht benötigen.

...Im Endeffekt wird C++ schon etwas schneller sein als C#, aber der Unterschied bewegt im einstelligen Prozentbereich. Und da auch nur bei sauberem C++, sonst kann man mit C++ leicht langsamere Programme schreiben.

Nach meiner eigenen Erfahrung (und ich mag C# eigentlich), ist der Unterschied mehr als messbar wenn in dem Programm nicht ständig die gleichen Methoden aufgerufen werden.

Es stimmt zwar das in der Theorie C# und Java schneller als C++ sein können, wenn Code sehr häufig aufgerufen wird. Doch in der Praxis gibt es viele Anwendungen bei denen die erstmalige Compilierung mehr Zeit kostet, als spätere Aufrufe retten können. Und Kunden vertröstet auch nur selten ein Spruch wie "Ab den 2ten Aufruf ist es schnell".

Das heißt nicht das ich C# nicht empfehlen kann, aber der Grund liegt eher in den geringeren Entwicklungsaufwand begründet, als in der Performance.

Es stimmt zwar das in der Theorie C# und Java schneller als C++ sein können [...]

Ein weiterer Grund, weshalb C++ in der Praxis oft schneller ist, ist der Programmierstil in den Sprachen. C#/Java sind rein objektorientiert angelegt, während in C++ mehr auf Templates gesetzt wird. Ein Iterator in C++ ist oft ein einfacher Pointer, in C# z.B. ist es ein Objekt, bei dem für jedes Vorrücken eine virtuelle Funktion aufgerufen werden muss, was natürlich um einiges langsamer ist.

Ich benutze in allen grösseren Projekten mit C++ sehr oft Garbage Collection auf Basis von Smart Pointern und einem Mark/Sweep + Generational Algorithmus - der GC kommt überall zum Einsatz, wo es mir sinnvoll erscheint. Der GC von .NET ist noch sehr viel ausgeklügelter (der Quellcode einer alten Version 2.0 steht offen zur Verfügung), aber seine Benutzung ist zwingend. Und es ist klar, was schneller ist als die beste GC Implementierung: Kein GC. Statischer Speicher und fertig. In vielen Fällen reicht das in C++ sogar aus. Das Argument mit dem Speichermanagement pauschal zieht also nicht wirklich.

lolelotte schrieb:

Ein weiterer Grund, weshalb C++ in der Praxis oft schneller ist, ist der Programmierstil in den Sprachen. (...) Ein Iterator in C++ ist oft ein einfacher Pointer, in C# z.B. ist es ein Objekt, bei dem für jedes Vorrücken eine virtuelle Funktion aufgerufen werden muss (...).

Das ist sehr richtig und nicht zu unterschätzen. Und man kombiniere nun diese Enumerator-Geschichte mit der Speicherverwaltung: Jeder Enumerator wird mit allem GC-Komfort in jeder Schleife neu auf dem GC angelegt und irgendwann wieder zerstört. Footprint: Ein Vielfaches eines Pointers, Indirektionen, virtuelle Calls, Verwaltung

PS: Ich liebe C# und in über 90% der Fälle sind diese Punkte irrelevant :p

Ich benutze in allen grösseren Projekten mit C++ sehr oft Garbage Collection auf Basis von Smart Pointern und einem Mark/Sweep + Generational Algorithmus - der GC kommt überall zum Einsatz, wo es mir sinnvoll erscheint.

Sowas gibts?

Statischer Speicher und fertig.

LOL.

Und man kombiniere nun diese Enumerator-Geschichte mit der Speicherverwaltung: Jeder Enumerator wird mit allem GC-Komfort in jeder Schleife neu auf dem GC angelegt und irgendwann wieder zerstört.

Ein GC zerstört nichts. Ein GC behält alles, was noch lebt, und vergisst den Rest einfach (Voraussetzung: Keine Finalizer).
Zerstören muss man in C++.

Sowas gibts?

Wieso sollte es sowas nicht geben?

Bashar schrieb:

Sowas gibts?

Wieso sollte es sowas nicht geben?

Erwartete Antworten von gut bis dämlich:

1. Ja, siehe http://...
2. Nein, hab mich geirrt.
3. Wieso nicht???ßß

asc schrieb:

Es stimmt zwar das in der Theorie C# und Java schneller als C++ sein können [...]

Ein weiterer Grund, weshalb C++ in der Praxis oft schneller ist, ist der Programmierstil in den Sprachen. C#/Java sind rein objektorientiert angelegt, während in C++ mehr auf Templates gesetzt wird.

Bitte mache nicht den Fehler dies per se auf die Objektorientierung zu schieben. Ich kann beispielsweise in C++ auch mit Ausnahme der main-Funktion rein Objektorientiert arbeiten, und dennoch muss es nichts kosten. Ausnahmen sind sicherlich virtuelle Funktionen, und die Tatsache das C#/Java jedem Objekt den GC aufzwingt. Aber letzteres hat erst einmal nichts mit dem OO-Paradigma zu tun.

asc schrieb:

Es stimmt zwar das in der Theorie C# und Java schneller als C++ sein können [...]

Ein weiterer Grund, weshalb C++ in der Praxis oft schneller ist, ist der Programmierstil in den Sprachen. C#/Java sind rein objektorientiert angelegt, während in C++ mehr auf Templates gesetzt wird. Ein Iterator in C++ ist oft ein einfacher Pointer, in C# z.B. ist es ein Objekt, bei dem für jedes Vorrücken eine virtuelle Funktion aufgerufen werden muss, was natürlich um einiges langsamer ist.

Das sind Peanuts und darauf wollte ich nicht hinaus. Ich wollte eher im Gegenteil weg von dieser "xyz ist schneller als yzx" Geschichte, ich kanns echt nicht hören. C# ist schnell genug und die Performance ist in 99% der Fälle kein Thema. Die Unterschiede sind zu 99% und nicht spürbar und nicht messbar. Wenn es explizit um extrem zeitkritische Anwendungen geht, dann würde man eher nicht C# nehmen. Aber ansonsten ist das Gerede über Performance völlig irrelevant und reine Zeitverschwendung.
Weiß nicht mehr wers gesagt hat, aber ich finds immer wieder gut: "The best optimizer is between your ears". Darauf wollte ich eigentlich hinaus. Dass man aus C++ theoretisch 2% mehr Performance herauskitzeln kann interessiert keinen. Unsere C++ Software in der Arbeit ist teilweise echt langsam. Da brauchen Operationen Minuten. Sind zwar komplexe Operationen, aber ganze ist über die Zeit dermaßen auseinandergewachsen, dass da Sachen zig mal berechnet und ausgeführt werden. Hat aber niemand Zeit, das umzubauen. Und das hat jetzt nichts mit der Programmiersprache zu tun. Nicht optimal aufgebaute Software, die man konzeptionell um mehrere Größenordnungen beschleunigen könnte, findet man sehr viel häufiger, als Software, wo die Programmiersprache irgendwas ausmacht.

Ich weiß nicht, wie es in C# ist, in Java ist jede Methode automatisch virtual.

Nein sind sie nicht.

Cyres schrieb:

Ich weiß nicht, wie es in C# ist, in Java ist jede Methode automatisch virtual.

Nein sind sie nicht.

Wikipedia schrieb:

Programmierer der Sprachen C++, SystemVerilog oder Object Pascal müssen sich explizit mit dieser Thematik auseinandersetzen und entscheiden, welche Methoden sie als „virtuell“ definieren. In anderen objektorientierten Programmiersprachen wie Java, Smalltalk und Python sind automatisch alle Methoden virtuell.

Stackoverflow schrieb:

All methods in java are virtual by default.

Soll ich nach weiteren Quellen suchen?

private und finale Methoden sind in Java nicht virtuell.

> "by default"
> "automatisch"
( Hat er etwas frei übersetzt )

private und finale Methoden sind in Java nicht virtuell.

Du meinst "private Methoden sind nicht virtuell sowie finale Methoden, die keine anderen überschreiben sind nicht virtuell", oder?