c++ vs. java... was hat zukunft
-
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.
-
.filmor schrieb:
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.
geworben?
ne, ich hab' mich weiter oben etwas über echtzeitsysteme ausgelassen, aber das von dir zitierte gilt dann wieder für gewöhnliche computer. sorry, hätt' ich vielleicht dazuschreiben sollen
-
Gregor schrieb:
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
huch?
fiese sache!
da haben die entwickler echt gepennt.
ich wär' ja dafür, der Java-sprache eine art 'forceinline' zu spendieren.
-
Gregor schrieb:
@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.Und diese Regeln hast du sicher auch irgendwo notiert (und wenn nur implizit - im Zweifelsfall stellt die Verzeichnisstruktur der JAR-Archivs dein ConfigFile dar)
Und wenn ich so klare Regeln ausarbeiten könnte, wäre das sicher auch für C++ möglich.(wir haben auf Arbeit ein Toolkit namens "VIP" auf VC-Basis, damit kann man recht einfach Filterketten zur Grafikverarbeitung zusammenbauen. Das dürfte schon fast in die Richtung gehen, die du angedeutet hast)
@pale dog: Ich hab' nichts gegen Java-Fans. Bei dir wundert mich nur immer wieder die Kombination "pro C", "pro Java" UND "kontra C++".
(und eventuell solltest du mal klarer herausstellen, welche deiner Aussagen jetzt für C gelten, welche für Java und welche allgemein gegen C++ ;))
-
CStoll schrieb:
@pale dog: Ich hab' nichts gegen Java-Fans. Bei dir wundert mich nur immer wieder die Kombination "pro C", "pro Java" UND "kontra C++".
(und eventuell solltest du mal klarer herausstellen, welche deiner Aussagen jetzt für C gelten, welche für Java und welche allgemein gegen C++ ;))"pro XYZ" ist doch eh ein Schubladendenken, das recht eingeschränkte Gültigkeit hat. Ich gehöre hier sicherlich zu den klassischen Java-Befürwortern. Trotzdem kannst Du von mir auch jede Menge kritische Äußerungen gegenüber Java lesen.
-
Gregor schrieb:
Trotzdem kannst Du von mir auch jede Menge kritische Äußerungen gegenüber Java lesen.
Von dir ja - von pale dog eher weniger
-
Man könnte sich doch mal eine Fallstudie überlegen
- nicht zu systemnahes; das wäre Java gegenüber etwas unfair
- Fliesskommaperformance lassen wir mal weg
- Mit C++ darf man Bibliotheken im Umfange der Java-EE hinzufügen; also z.B. GUI-Bibliotheken; Boost; ATL/COM, MICO/Orbeit, ... und dergleichen whatever we like
- [...] ???Wie wär's denn mit sowas:
- Eine SQL-Datenbank mit drei Tabellen ( (m:n) plus die Hilfstabelle ); ein BLOB-Feld und ein TEXT Feld dabei
- Ein RPC-Server für (Win32 und Linux) der den BLOB verarbeitet z.B. Base64Encoded, eine Volltextsuche über dem TEXT Feld anbietet und (String)-Ergebnisse als XML zurückliefert (all dies mit beliebiger Technik).- Ein Standalone-GUI jeweils für Win32 und Linux/X
- Ein Intranet Client ( Whatever we like )Wäre das nicht ein praxisnaher Masstab?
Grüsse
*this
P.S.: Ich würde es bei Bedarf auch in MySQL/Python/Tix prototypisieren - das spart ein Pflichtenheft.
-
pale dog schrieb:
Konrad Rudolph schrieb:
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.
Wozu? Genau dafür hat man doch die C++-Templates. Oder willst Du C++ nicht verwenden, weil es gegenüber C irgendwelche gravierenden Nachteile hat? Welche?
Ich sehe C++ nach wie vor als besseres C an und habe bisher noch kein überzeugendes Gegenargument hören können.
-
Konrad Rudolph schrieb:
pale dog schrieb:
Konrad Rudolph schrieb:
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.
Wozu? Genau dafür hat man doch die C++-Templates. Oder willst Du C++ nicht verwenden, weil es gegenüber C irgendwelche gravierenden Nachteile hat? Welche?
Ich sehe C++ nach wie vor als besseres C an und habe bisher noch kein überzeugendes Gegenargument hören können.
Es ist einfach so, dass in vielen Projekten C eingesetzt wird. Über die Gründe kann man sicherlich diskutieren, ist aber eigentlich egal.
-
Konrad Rudolph schrieb:
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.
Gibt es für "rein" generische Programmierung Musterkataloge die in ihrem Umfang den GoF Pattern vergleichbar sind?
In mehreren Bereichen würde ich's vermuten, abar bei dem "24." Muster, das die GoF implizit benutzt, nämlich "Client -> Abstrakte Schnitstelle <= Konkrete Implementierung" weiss ich nicht wie man das generisch implementieren kann.
Grüsse
*this
P.S.: @Konrad Rudolph : Hat das mit dem bitset funktioniert?
-
CStoll schrieb:
@pale dog: Ich hab' nichts gegen Java-Fans. Bei dir wundert mich nur immer wieder die Kombination "pro C", "pro Java" UND "kontra C++".
(und eventuell solltest du mal klarer herausstellen, welche deiner Aussagen jetzt für C gelten, welche für Java und welche allgemein gegen C++ ;))hauptsächlich eigene erfahrungen aber auch geschichten, die man von anderen hört (und auch die problemchen, mit denen sich manche hier auf board dem herumärgern).
z.b. kenne ich einen, der programmierkurse gibt.
wenn er C und C++ unterrichtet sagt er in etwa: 'mit C haben die leute schon probleme, die meisten schnallen's dann doch, aber mit C++ kommen die wenigsten (einsteiger) noch klar'.
über seine Java-kurse sagt er: 'wenn die grösste hürde (OOP, vererbung, etc.) erstmal genommen ist, geht alles recht flüssig.
dementsprechend weit kommen sie auch im Java-kurs, zum schluss machen sie eine swing-anwendung mit anbindung an eine SQL-datenbank und tortengrafik (so'ne wahlstimmenauszählung) drin usw. und die schüler sind hochzufrieden.
im C/C++ kurs kommen sie bis etwa 'class Auto : public Fahrzeug' und die schüler sind gefrustet.
man könnte ihm zwar vorwerfen, warum er erst mit C anfängt, und dann mit C++ weitermacht, aber er hat es schon versucht, gleich mit C++ loszulegen. das hat leider auch nicht funktioniert. offenbar muss man für C++ gewisse grundkenntnisse haben, die man etwa in einem C kurs mitbekommt.