c++ vs. java... was hat zukunft
-
pale dog schrieb:
...
meine transferleistung war, default copy-ctors mit einer eigenschaft einer nicht-OO sprache zu vergleichen, ..... aber sie reicht doch auch bestimmt soweit, diese Eigenschaft verkürzend als "Default-Konstruktor" bennen zu dürfen, oder ?
"C++ ist besser als C" habe ich nicht gesagt; das Vergleichen hast Du eingeführt ("Das kann C auch") und ich habe lediglich darafu hingewiesen, dass das Konstruktionsverhalten in C++ schon etwas komplexer ist als in C.
Dem stimmst Du wahrscheinlich sowieso zu, weswegen ich auch gar nicht weiß, worüber wir uns hier streiten sollten.
Dass Du mit CStoll einen eigenen Disput hast, braucht uns ja wohl nicht zu stören, oder ?
Gruß,
Simon2.
-
CStoll schrieb:
Serialisierung als solche ist sicher ein nützliches Feature (und in C++ möglicherweise komplizierter umzusetzen). Aber damit hast du mir immer noch nicht erklärt, warum man Java Objekte nicht direkt (und mit jeder Semantik, die ich für mein Objekt für sinnvoll erachten mag) kopieren kann.
das geht ja auch, indem man die 'Object.clone()' methode überschreibt. die default-version liefert eine flache kopie, in einer überschriebenen methode kann man das verhalten ändern wie man möchte.
allerdings ist davon abzuraten, sich mit 'clone()' tiefes kopieren selbst hinzufrickeln, weil ObjectOutput/ObjectInput-Streams das viel besser können (sie benutzen die 'reflection'-möglichkeiten der VM).
-
[quote="pale dog]naja, ganz so würde ich das nicht sehen. mit C# ist natürlich einiges mehr möglich, wenn's um windows geht, aber Java ist auch unter windows durchaus eine brauchbare alternative.
[/quote]Das kann nur von jemand kommen der noch keine größeren Projekte mit C# gemacht hat und die Sprache + .Net nur vom Hörensagen kennt... Sorry, im Vergleich zu C# + .Net unter Windows ist Java _keine_ Alternative wenn Aspekte wie Wirtschaftlichkeit und Einhalten von engen Deadlines im Vordergrund stehen...
[quote="pale dog]
eher C ohne ++. C++ hat einige versteckte bremsen und fallstricke, die bei performancekritischen programmen böse überraschungen bescheren können. selbst die abgespeckte variante 'embedded C++' erfreut sich in der fachwelt keiner grossen beliebtheit.
[/quote]Ab einer gewissen Projektgröße überwiegen die Vorteile von OOP im Bezug auf Wartbarkeit, Erweiterung etc eindeutig den Performancenachteilen gegenüber reinem C. C++ imho daher immer die erste Wahl und wenns überhaupt nicht anders geht, höchstens einzelne Module innderhalb der Projektes in reinem C.
Vorraussetzung natürlich man kann mit OOP umgehen, eine Fähigkeit die ich vielen abspreche, vor allem wenn ich solche Kommentare lese...
-
pale dog schrieb:
CStoll schrieb:
Serialisierung als solche ist sicher ein nützliches Feature (und in C++ möglicherweise komplizierter umzusetzen). Aber damit hast du mir immer noch nicht erklärt, warum man Java Objekte nicht direkt (und mit jeder Semantik, die ich für mein Objekt für sinnvoll erachten mag) kopieren kann.
das geht ja auch, indem man die 'Object.clone()' methode überschreibt. die default-version liefert eine flache kopie, in einer überschriebenen methode kann man das verhalten ändern wie man möchte.
Und damit sind wir wieder am Anfang der Diskussion - worin (abgesehen vom Namen) unterscheidet sich 'Object.clone()' von einem überladenen operator=?
allerdings ist davon abzuraten, sich mit 'clone()' tiefes kopieren selbst hinzufrickeln, weil ObjectOutput/ObjectInput-Streams das viel besser können (sie benutzen die 'reflection'-möglichkeiten der VM).
Wie gesagt, "flache Kopie" und "tiefe Kopie" sind nur zwei mögliche Konzepte. Und den Umweg über einen Stream halte ich immer noch für zumindest unintuitiv.
(würdest du wichtige Informationen für deinen Kollegen, der im selben Zimmer sitzt, mit der Post verschicken? Vermutlich ja :D)
-
Gregor schrieb:
Für mich geht es beim Programmieren nur um die Algorithmen, die auch wirklich neuartige Funktionalität mit sich bringen. Alles andere ist stinklangweilig. LAME! Programmierst Du, um andauernd den gleichen niveaulosen 08/15-Mist zu schreiben? Wie kann man daran Interesse entwickeln?
Naja, aber gerade Java wird hier ja schnell langweilig. Ich meine wo ist zB der Sinn davon das man bei Annotations nur bestimmte Klassen zulässt? Warum lässt man sich so etwas einfallen? Eine Implementationsabhängige Entscheidung kann das ja nicht sein, da man ja bestimmte Klassen zulässt und es also nicht an Klassen liegen kann. Gerade so etwas erstickt doch die Kreativität und Möglichkeiten.
Oder warum funktionieren Generics nicht für Builtin-Typen (ok, weil es wie ich schon gesagt habe in Java eben Typen und Klassen gibt und das ist was unterschiedliches aus irgend einem Grund).
Aber gerade solche Sachen finde ich an Java leider sehr schade. Man wird zum Teil in seiner Kreativität beraubt, weil die Java-Entwickler genau einen Weg für viele Sachen für richtig halten und einem aufzwingen. Das ist eben eine Programmiersprache die von oben für _andere_ entwickelt wird.
Sicher kommt ihr jetzt damit, das Kreativität nicht wichtig sei und man nur das Projekt fertig stellen muss. Aber ich finde Kreativität ist schon sehr wichtig. Dadurch kommt man nämlich zu besseren oder gar schneller zu einer Lösung (zB so etwas wie Boost.Spirit in C++ oder RubyOnRails in Ruby).
Und klar hat Java eine tollere Reflections-API als C++, weil C++ keine Reflections-API hat. Aber wiederum gibt es Programmiersprachen die mir in dem Bereich mehr ermöglichen.
Ich sehe in Java einfach keinen wirkliche Mehrwert. Oder machen wir es mal so: Welche Innovation bietet mir Java? Worum kann mich Java bereichern? (Und das meine ich _nicht_ im Vergleich zu C++)
-
lokos schrieb:
Sorry, im Vergleich zu C# + .Net unter Windows ist Java _keine_ Alternative wenn Aspekte wie Wirtschaftlichkeit und Einhalten von engen Deadlines im Vordergrund stehen...
...wie kommst du darauf?
lokos schrieb:
Ab einer gewissen Projektgröße überwiegen die Vorteile von OOP im Bezug auf Wartbarkeit, Erweiterung etc eindeutig den Performancenachteilen gegenüber reinem C.
du hattest zeitkritische programme, realtime etc. erwähnt und dabei sind nun mal geschwindigkeit und schnelle, vorhersehbare reaktionszeiten das maß aller dinge.
CStoll schrieb:
pale dog schrieb:
CStoll schrieb:
Serialisierung als solche ist sicher ein nützliches Feature (und in C++ möglicherweise komplizierter umzusetzen). Aber damit hast du mir immer noch nicht erklärt, warum man Java Objekte nicht direkt (und mit jeder Semantik, die ich für mein Objekt für sinnvoll erachten mag) kopieren kann.
das geht ja auch, indem man die 'Object.clone()' methode überschreibt. die default-version liefert eine flache kopie, in einer überschriebenen methode kann man das verhalten ändern wie man möchte.
Und damit sind wir wieder am Anfang der Diskussion - worin (abgesehen vom Namen) unterscheidet sich 'Object.clone()' von einem überladenen operator=?
wahrscheinlich gar nicht
ausser, dass 'clone()' in java eher selten benutzt wird.
-
CStoll schrieb:
@Gregor: Wie gesagt, woher weiß Java, welche deiner Klassen wo und wie zusammengestellt werden sollen? Egal wo das ist, irgendwo mußt du diese Information auch abgelegt haben.
Konstruktoren und Methoden haben Parameter. Die bestimmen größtenteils, was in den Dialogen drin steht und was für Dialoge generiert werden. ...und die werden letztendlich durch den Nutzer ausgelöst. ...du gehst ins Menu, klickst da auf irgendeinen Punkt und es erscheint ein Dialog. ...wie in vielen anderen Programmen auch. Ich sehe nicht ganz, wo das Problem ist?
-
Gregor schrieb:
CStoll schrieb:
@Gregor: Wie gesagt, woher weiß Java, welche deiner Klassen wo und wie zusammengestellt werden sollen? Egal wo das ist, irgendwo mußt du diese Information auch abgelegt haben.
Konstruktoren und Methoden haben Parameter. Die bestimmen größtenteils, was in den Dialogen drin steht und was für Dialoge generiert werden. ...und die werden letztendlich durch den Nutzer ausgelöst. ...du gehst ins Menu, klickst da auf irgendeinen Punkt und es erscheint ein Dialog. ...wie in vielen anderen Programmen auch. Ich sehe nicht ganz, wo das Problem ist?
Ich glaube, wir reden aneinander vorbei
Woher weiß das Menü, welche Punkte es anzeigen soll? Woher weiß es, wie der daraufhin entstehende Dialog aussehen soll? ...?Oder allgemeiner: Woher weiß dein System, wann es welchen Konstruktor bzw. welche Methode mit welchen Parametern aufrufen muß?
@pale dog: Wenn du die Möglichkeiten von C++ vernünftig nutzt, mußt du dich auch nicht mit dem operator= herumschlagen (ja ich weiß, C++ hat keinen Garbage Collector, aber dafür reichlich Klassen, die dir die Speicherverwaltung und ähnliches abnehmen).
du hattest zeitkritische programme, realtime etc. erwähnt und dabei sind nun mal geschwindigkeit und schnelle, vorhersehbare reaktionszeiten das maß aller dinge.
Und in diesen Punkten steht Java besser da als C++?
-
CStoll schrieb:
du hattest zeitkritische programme, realtime etc. erwähnt und dabei sind nun mal geschwindigkeit und schnelle, vorhersehbare reaktionszeiten das maß aller dinge.
Und in diesen Punkten steht Java besser da als C++?
nö, nicht Java.
hier hat jemand geschrieben, dass C++ das nonplusultra für realtime-software sei:Bei reiner Systementwicklung, Realtime-Anwendungen und Performancekritischen Sachen wieder denke ich das C++ am meisten Punktet und auch hier noch lange Zeit einfach dei Sprache der Wahl sein wird.
...und das kann man nicht kommentarlos stehen lassen
aber ich meine nicht, dass man dafür Java nehmen sollte.
du musst mich wohl für ganz schön blöd' haltenCStoll schrieb:
(ja ich weiß, C++ hat keinen Garbage Collector, aber dafür reichlich Klassen, die dir die Speicherverwaltung und ähnliches abnehmen).
jaja, eine menge unterschiedlicher 'smart pointer' u.ä. zeug, der eine hierfür, ein anderer dafür....
nee, lass mal
-
Auf der Performance-Seite hat C++ auf jeden Fall den Bonus, daß du immer noch direkt alles nutzen kannst, was du aus C kennst. (und außerdem ging es dabei nicht um C, sondern um den direkten Vergleich C++ vs. Java)
PS: Afaik gibt es keine GC-artige Verwaltung für andere Betriebsmittel in Java. Das heißt, die Speicherverwaltung wird mir zwar von der JVM abgenommen, aber wenn ich mit eigenen kritischen Ressourcen umzugehen habe, bin ich wieder auf mich selbst gestellt.
-
CStoll schrieb:
Auf der Performance-Seite hat C++ auf jeden Fall den Bonus, daß du immer noch direkt alles nutzen kannst, was du aus C kennst.
Das ist doch Pillepalle. Der Performance-Vorteil von C++ ist, dass man generisch programmieren kann und somit einen sehr hohen Grad an Abstraktion erreicht, *ohne* (im Gegensatz zu OOP) Performance-Einbuße in Kauf nehmen zu müssen. *Das* ist der Vorteil von C++ vor den meisten anderen Sprachen und damit auch Java. Wenn man diesen Vorteil nicht nutzt, kann man auch, je nach Anforderung, C oder Java verwenden.
/EDIT Shit. Ich hab gedacht, diesmal käme ich drumherum, mich einzumischen.
-
pale dog schrieb:
du musst mich wohl für ganz schön blöd' halten
Zur Abwechslung mal ein Punkt in dem wir uns Diskussionslos einig sind
-
lokos schrieb:
Anders sieht es bei Applicationen aus die entweder auf möglichst vielen Plattformen laufen sollen oder halt von vorneherein *nix basiert sind, da wird Java noch lange Zeit die Nase vorne haben wohingegen C++ hier schon jetzt kaum eine Gegenwart hat.
Eine Vielzahl meiner *nix - Programme laufen ohne installierte Java-VM. Mag sein dass sich das noch ändert.
Unter Linux mag es Bezeichnend sein dass GNOME/GTK+ ein C Framwork ist und KDE/Qt C++. Ich denk doch da gibts für C & C++ durchaus Zukunft in der Anwendungswelt.
lokos schrieb:
Ab einer gewissen Projektgröße überwiegen die Vorteile von OOP im Bezug auf Wartbarkeit, Erweiterung etc eindeutig den Performancenachteilen gegenüber reinem C. C++ imho daher immer die erste Wahl und wenns überhaupt nicht anders geht, höchstens einzelne Module innderhalb der Projektes in reinem C.
Komisch ,dass dann wirklich große Projekte wie der Linux-Kernel immer noch C sind.
-
Hallo,
ihr hat alle weit verfehlt ^^ ob java oder C++, beide haben keine Zukunft, diese gehört einzig und alleine der neuen Programmiersprache 'D' :þ
-
d3rbastl3r schrieb:
ihr hat alle weit verfehlt ^^ ob java oder C++, beide haben keine Zukunft, diese gehört einzig und alleine der neuen Programmiersprache 'D' :þ
Und wovon träumst du nachts? Sicher wird D auch seine Nische finden, aber um C++ oder Java die Anwender abzugraben, muß es schon mehr zu bieten haben als eine Propaganda-Page ala "wir sind besser als alle anderen".
-
Konrad Rudolph schrieb:
CStoll schrieb:
Auf der Performance-Seite hat C++ auf jeden Fall den Bonus, daß du immer noch direkt alles nutzen kannst, was du aus C kennst.
Das ist doch Pillepalle. Der Performance-Vorteil von C++ ist, dass man generisch programmieren kann und somit einen sehr hohen Grad an Abstraktion erreicht, *ohne* (im Gegensatz zu OOP) Performance-Einbuße in Kauf nehmen zu müssen. *Das* ist der Vorteil von C++ vor den meisten anderen Sprachen und damit auch Java.
ja, templates sind eine feine sache und manchmal wünsche ich mir, dass ähnliches mit dem C preprozessor möglich wäre.
trotzdem müssen auch echtzeitanwendungen zur laufzeit entscheidungen treffen und dabei können ihnen templates leider nicht helfen.
ausserdem hat man (nehme ich an) bei templates auch weniger einfluss auf die codeerzeugung, aber wenn's um mikrosekunden geht, ist das manchmal wichtig.btw, damit vm-sprachen hierbei nicht ganz alt aussehen:
so'ne vm hat die möglichkeit zur laufzeit den code zu optimieren (jit-compiler) und ihre 'virtuellen maschinenparameter' an die umgebung anzupassen. es wäre schon denkbar, dass in manchen situationen ein vm-programm scheller läuft, als eine statische 'exe'.
-
pale dog schrieb:
Konrad Rudolph schrieb:
CStoll schrieb:
Auf der Performance-Seite hat C++ auf jeden Fall den Bonus, daß du immer noch direkt alles nutzen kannst, was du aus C kennst.
Das ist doch Pillepalle. Der Performance-Vorteil von C++ ist, dass man generisch programmieren kann und somit einen sehr hohen Grad an Abstraktion erreicht, *ohne* (im Gegensatz zu OOP) Performance-Einbuße in Kauf nehmen zu müssen. *Das* ist der Vorteil von C++ vor den meisten anderen Sprachen und damit auch Java.
ja, templates sind eine feine sache und manchmal wünsche ich mir, dass ähnliches mit dem C preprozessor möglich wäre.
trotzdem müssen auch echtzeitanwendungen zur laufzeit entscheidungen treffen und dabei können ihnen templates leider nicht helfen.
ausserdem hat man (nehme ich an) bei templates auch weniger einfluss auf die codeerzeugung, aber wenn's um mikrosekunden geht, ist das manchmal wichtig.Warum sagst du sowas? Ich weiß sehr genau, was mir der Compiler generiert, wenn ich Templates verwende. Und ich weiß auch, das solche Programme heftigst optimiert werden und sauschnell laufen (nämlich so schnell wie das C-Pendant).
Und wenn ich mich doch einmal nicht auf seine Optimierung verlassen will oder kann, dann schreib ich das entsprechende Codestück halt in C und binde es in das übrige C++-Programm ein. Genauso verfahre ich, wenn ich einen Programmteil sehr dynamisch halten will, weil er sich oft ändert (GUIs sind da ein gutes Beispiel). Boost.Python her und *schwupps*, schon hab ich alles, was ich an Reflection oder anderen feinen Sachen an Sprachen mit dynamischen Typsystem brauche.pale dog schrieb:
btw, damit vm-sprachen hierbei nicht ganz alt aussehen:
so'ne vm hat die möglichkeit zur laufzeit den code zu optimieren (jit-compiler) und ihre 'virtuellen maschinenparameter' an die umgebung anzupassen. es wäre schon denkbar, dass in manchen situationen ein vm-programm scheller läuft, als eine statische 'exe'.Blah. Das ist doch absolut inhaltsleer. Eben noch hast du für Vorhersagbarkeit geworben.
-
Wie steht es?
Hat Java schon gewonnen?
-
pale dog schrieb:
btw, damit vm-sprachen hierbei nicht ganz alt aussehen:
so'ne vm hat die möglichkeit zur laufzeit den code zu optimieren (jit-compiler) und ihre 'virtuellen maschinenparameter' an die umgebung anzupassen. es wäre schon denkbar, dass in manchen situationen ein vm-programm scheller läuft, als eine statische 'exe'.Eine Optimierung zur Laufzeit kostet natürlich beim startup, während ein statischer Compiler da deutlich mehr _Zeit_ hat.
Und um sich an die Lokalen verhältnisse besser anzupassen müsste die vm schon für jedes noch so spezielle target individuelle optimierungen anbieten, und die kann ich auch mit optionen bei einem statischen Kompiler erreichen wenn ich sie brauche.nur mal so schrieb:
Wie steht es?
Hat Java schon gewonnen?Momentan wird C gegen C++ gespielt, Java ist schon raus.
-
pale dog schrieb:
so'ne vm hat die möglichkeit zur laufzeit den code zu optimieren (jit-compiler) und ihre 'virtuellen maschinenparameter' an die umgebung anzupassen. es wäre schon denkbar, dass in manchen situationen ein vm-programm scheller läuft, als eine statische 'exe'.
Denkbar ist vieles. Aber man lebt nunmal in der Realität. Und wenn man die Performance vergleicht, hat man es schwer, solche Fälle zu finden. Menschen schreiben Programme und damit auch Compiler. Und da kommen halt Compiler für C++ raus, die schnelleren Code produzieren, als der Hotspot-Jitter von Java. Sicherlich gibt es theoretische Möglichkeiten, Laufzeitinformationen zur weiteren Optimierung zu nutzen und das wird - in sehr geringem Maße - auch gemacht. Im Großen und Ganzen muss man aber auch beachten, dass sich der Hotspot-Jitter nicht so viel Zeit wie ein C++ Compiler nehmen kann. Schließlich geht es zur Laufzeit in erster Linie darum, dass das Programm läuft: Da kann man es nur schwer vertreten, minutenlange Pausen einzubauen, damit man irgendwo noch 2% Performance rausholt.
Trotzdem verbessert sich die Performance von Java natürlich von Version zu Version. Wenn man sich die Bug-Fixes anschaut, ist man sogar sehr überrascht, welch simple und effektive Performancesteigerungen selbst in Version 7 noch eingebaut werden. ...man sollte denken, das Java schon ausgereifter wäre. Naja, aber wie schon gesagt: Das wird von Menschen geschrieben. Und die entdecken auch nach 10 Jahren nochmal, dass jemand mal nicht so sehr auf irgendetwas bestimmtes geachtet hat. Sei es nun aus Fahrlässigkeit oder deshalb, weil damals noch eine völlig andere Infrastruktur anzutreffen war.
Mein momentanes Musterbeispiel dafür ist in einem ganz zentralen Bereich der Standardbibliothek anzutreffen: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5103956
Naja, aber genauso werden die C++ Compiler natürlich auch immer besser.
@CStoll: Ich wollte die Innereien meines privaten Projekts eigentlich nicht in dem Maße thematisieren, wie ich es hier leider doch angefangen habe. Ich denke, das ist ein bischen Offtopic. Deshalb werde ich dazu nichts mehr sagen. Nur so viel: Es funktioniert.
...wobei die Mechanismen, die ich mir da überlegt habe, sicherlich vom allgemeinen Problembereich des Projekts profitieren. Der ermöglicht es, sehr allgemeine Regeln für die Zusammensetzung von Dialogen usw. zu formulieren.Vielleicht werde ich das Projekt irgendwann mal unter einer OSS-Lizenz veröffentlichen. Dann kannst Du Dir das angucken, falls Dich das dann noch interessiert.