C++ oder C#
-
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.
-
Zeus schrieb:
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.
-
Bashar schrieb:
private und finale Methoden sind in Java nicht virtuell.
> "by default"
> "automatisch"
( Hat er etwas frei übersetzt )
-
Bashar schrieb:
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?
-
hustbaer schrieb:
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 Qt gibt es bereits eine solche Library.
-
Die Bibliothek von QT und die STL verfolgen allerdings 2 unterschiedliche Ziele
-
LordJaxom schrieb:
Bashar schrieb:
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?
Äh, ja
-
KuhTee schrieb:
hustbaer schrieb:
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 Qt gibt es bereits eine solche Library.
Nein.
-
Ich wollte jetzt eigentlich gar nicht drauf antworten, aber was solls...
Hier tun alle irgendwie so rum, als würden sie die ganze Zeit ausschließlich an ultra-performance kritischen Anwendungen arbeiten, wo die virtuellen Methoden den Ausschlag geben.
Ich bin aber davon überzeugt, dass es in Wirklichkeit eigentlich niemanden interessiert. Und wenn man in der Arbeit doch solche Überlegungen macht, dann ist man fehl am Platz - premature optimization is the root of all evil.
Beim Design einer Anwendung (und ich rede explizit nicht von absolut performancekritischen Teilen, die extrem selten sind) sollte sowas wie virtuelle Methode oder nicht überhaupt keine Rolle spielen. Tut es auch nicht. Man braucht in erster Linie eine saubere, erweiterbare, wartbare Architektur. Dementsprechend designed man das Programm auch. Und dabei kommen auch virtuelle Methoden vor, und pimpl (OMG, ein new!!!) und shared data vielleicht auch mal paar Abstraktionsebenen mehr. Und es ist immer noch alles in 99% der Fälle sehr viel schneller als schnell genug. Und wenn es mal Stellen gibt, wo man sagt, die Software braucht mit sehr großen Datenmengen einfach ein bisschen zu lang und fühlt sich etwas träge an, dann kommt wohl auch niemand daher und sagt OMG, hätt ich doch bloß auf die virtuelle Methode verzichtet! Dann schaut man eher, dass man Berechnungen zwischenspeichert oder nicht mehrfach ausführt, Caches einführt, schlauere Algorithmen implementiert usw.
Mal davon abgesehen kann ein just in time compiler (zumindest theoretisch, ob es in der Praxis auch funktioniert hat mich nie interessiert) virtuelle Methoden auch inlinen.
-
Mechanics schrieb:
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.
Mechanics schrieb:
Und es ist immer noch alles in 99% der Fälle sehr viel schneller als schnell genug.
Du wiederholst dich. Wenn dir Performanzunterschiede von Faktor 2 (mehr kann man mit C++ auch nicht rausholen) egal sind, dann ist für dich vielleicht eine andere Sprache besser geeignet als C++. Im Ernst, wozu C++? In C# ist die Kompilierzeit 100 mal schneller und du kannst schnell die GUI RADen und es ist auch für die weniger erfahrenen Programmierer geeignet.
In C++ kannst du auf Programmierebene die gleichen Abstraktionen nutzen, mit etwas mehr Schreibaufwand, dafür ohne Overhead. Der grosse Vorteil ist aber, dass für die kritischen 1% praktisch optimaler Assemblercode generiert werden kann. Du hast immer die Möglichkeit, bis ans Optimum zu optimieren, bei anderen Sprachen geht das kaum (man kann zwar C-Funktionen aufrufen, aber die Zeit, die man zum Mappen der Datentypen benötigt hebt den Vorteil wieder auf).
Es gibt genug Anwendungen, wo es drauf ankommt. Server, Bildbearbeitung, Simulationen, z.T. Spiele. Es gibt auch genügend Anwendungen, wo es nicht drauf ankommt (deine zum Beispiel).
asc schrieb:
lolelotte schrieb:
C++ [ist] in der Praxis oft schneller [...] 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 schiebe es auf reine Objektorientierung. Schonmal Event-Handling mit Klassen versucht? Schonmal std::sort in Java (und konsequenterweise ohne Generics) nachprogrammiert, insbesondere mit einstellbarer
SortierfunktionSortierobjekt? Eine gelungene Sprache darf sich eben nicht auf reine Objektorientierung einschränken. Du wirst kaum ein C++-Projekt in etwas was ich "reine OOP" nenne (d.h. ohne freie Funktionen und Templates u.ä.) finden.
-
lolelotte schrieb:
Schonmal std::sort in Java (und konsequenterweise ohne Generics) nachprogrammiert,
Wieso konsequenterweise? Generics sind Teil der Sprache und konsequent ist nur, wenn man in den Sprachen die man vergleicht auch den vollen Funktionsumfang berücksichtigt.
-
lolelotte schrieb:
Schonmal Event-Handling mit Klassen versucht?
Und wo liegt hierbei das Problem?
Ich meine, ich mag das Eventsystem aus C# mitdelegateauch besser, aber wenn man es genau nimmt, stellt dies nur Syntaxzucker dar.lolelotte schrieb:
Du wirst kaum ein C++-Projekt in etwas was ich "reine OOP" nenne (d.h. ohne freie Funktionen und Templates u.ä.) finden.
Jetzt definierst du bereits was OOP heisst? Womöglich liegt auch darin das Problem?
Grüssli
-
Freie Funktionen widersprechen reiner OOP imo schon, das ist ja gerade der Witz, dass nichts frei rumliegt. Aber Generics... wieso widersprechen die OOP?
-
Eisflamme schrieb:
Freie Funktionen widersprechen reiner OOP imo schon, das ist ja gerade der Witz, dass nichts frei rumliegt. Aber Generics... wieso widersprechen die OOP?
Sag mal das unter dem Gesichtspunkt Funktion == Objekt noch einmal. o.O
-
Eisflamme schrieb:
Freie Funktionen widersprechen reiner OOP imo schon, das ist ja gerade der Witz, dass nichts frei rumliegt. Aber Generics... wieso widersprechen die OOP?
Und was ist an statischen Funktionen in nicht instanzierbaren Pseudoklassen jetzt "objektiger" als an freien Funktionen?
Konzeptuell mMn. nix.Wenn du das (=Funktionen sinnloserweise in Pseudoklassen packen) in C++ machst wird dir jeder nen Vogel zeigen. Wenn man es in C# oder Java macht ist es objektig und gut. Vollkommen logisch!!!
-
Funktionen sind für mich aber keine Objekte.
hustbaer: Meine Rede. Aber ich habe ja nie behauptet, dass Java rein OOP ist
Diese Inkonsequenz (die jedoch zeigt, dass reines OOP einfach Käse ist) sehe ich ja durchaus auch.
-
Eisflamme schrieb:
Funktionen sind für mich aber keine Objekte.
fuer dich vielleicht.
In JavaScript zB hat eine Funktion intern immer einen this "Zeiger" und hat attribute und kann sogar funktionen als member haben...Funktionen sind ganz normale Objekte. In vielen Situationen kannst du zB garnicht zwischen Funktion und Objekt unterscheiden - betrachte zB mal predicates in STL Algos.
