C++ oder C#
-
Ich glaube, ich habe nie einen so guten Vergleich gelesen
-
pumuckl schrieb:
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.
-
hustbaer schrieb:
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?"
-
In einem "Going Native" Vortrag den ich letztens angesehen habe hat jemand (ich Herb Sutter) ein wenig geplaudert zum Thema Proposals (für neue Library Funktionen).
U.a. wurde da gesagt dass es halt viel Aufwand ist, weil man dann zu den Meetings kommen muss etc.
Davon dass man, damit man zu den Meetings kommen darf, erstmal Mitglieg der ISO werden muss, hat er nichts gesagt. Würde mich auch sehr wundern.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.
-
Ansehen und abstimmen sind vermutlich zwei verschiedene Dinge.
-
Der große Unterschied ist, dass C, C++ und ObjC direkt in Maschinencode umgewandelt wird, während C# und C++/CLI in die sogenannte Common Intermediate Language umgesetzt werden und von der CLR-Laufzeitumgebung (.Net bzw. Mono) bzw. im Falle von C++/CX von der WinRT-Laufzeitumgebung interpretiert werden.
C, C++ und ObjC sind daher effizienter, da sie diesen Umweg nicht benötigen.
-
Ich denke, bei C++/CX wird nichts
interpretiertgejitted, das ist ja COM unter der Haube.
-
Da wird überhaupt nichts interpretiert, egal ob WinRt oder nicht. Das ist ein Just in Time Compiler, der eben zur Laufzeit Maschinencode generiert und nicht zur Compilezeit. Das muss nicht einmal unbedingt langsamer sein, weil man bei Just in Time Kompilierung auch einiges optimieren kann, was beim statischen Kompilieren nicht geht. 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.
-
lol
-
was lol?
selber lol.
schreib was du meinst, oder zitiere wenigstens das belolte.
-
Mechanics schrieb:
...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.
-
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.
-
Praktisch alles, was C# kann, kann man auch in C++ sehr komfortabel machen. Ausnahmen sind aber z.B. Reflection Emit, was eine massive Runtime wie das .NET Framework voraussetzt (welches mit C# laut Spezifikation nicht unbedingt etwas zu tun hat). Und natürlich kommt der Komfort zu einem gewissen Preis, insbesondere weil er bei C# aufgezwungen wird. Gerade dein Beispiel mit der Speicherverwaltung ist hier schön.
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
-
/rant/ schrieb:
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++.
-
Bashar schrieb:
Sowas gibts?Wieso sollte es sowas nicht geben?
-
Kellerautomat schrieb:
Bashar schrieb:
Sowas gibts?Wieso sollte es sowas nicht geben?
Erwartete Antworten von gut bis dämlich:
- Ja, siehe http://...
- Nein, hab mich geirrt.
- Wieso nicht???ßß
-
lolelotte schrieb:
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.
-
Ich weiß nicht, wie es in C# ist, in Java ist jede Methode automatisch virtual.
-
lolelotte schrieb:
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.
-
Cyres schrieb:
Ich weiß nicht, wie es in C# ist, in Java ist jede Methode automatisch virtual.
Nein sind sie nicht.
