c++ vs. java... was hat zukunft
-
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.
-
damit geht java mit 17:14 in führung. jetzt muss c++ nachlegen.
-
ref schrieb:
damit geht java mit 17:14 in führung. jetzt muss c++ nachlegen.
Nein, wenn überhaut ist der Stand 16:14; "einfach in die Sprache einsteigen können" sagt nichts über die Tauglichkeit der Sprache für grosse Projekte aus!
Das ist in etwas so als habe man "Scribble"(MFC C++ Demo App) geschrieben und meine damit etwas über die Verwendung der MFC in C/S Umgebungen aussagen zu können.
Mit Einsteigern alleine kann man kein Projekt realisieren; vielmehr glaube ich dass diese fehlerhafte Interpolation der Lernkurve/Erfolgsquote für den größten Teil der Probleme mit Java verantwortlich ist.
Grüsse
*this
P.S.: Hiernach dann mindestens 15:16 wegen "Java-Lernkurvenmythos demontiert"
-
Gast++ schrieb:
Nein, wenn überhaut ist der Stand 16:14; "einfach in die Sprache einsteigen können" sagt nichts über die Tauglichkeit der Sprache für grosse Projekte aus!
nun, Java wurde für 'richtig grosse' projekte entwickelt, und wird auch dort erfolgreich eingesetzt, daran gibt's nichts zu deuteln. jemand, der programmierer für ein grosses projekt sucht, wird auch eher Java programmierer finden, denn wirklich fähige C++ programmierer sind (bedingt durch die komplexität der sprache) wirklich rar gesät.
Gast++ schrieb:
Das ist in etwas so als habe man "Scribble"(MFC C++ Demo App) geschrieben und meine damit etwas über die Verwendung der MFC in C/S Umgebungen aussagen zu können.
gutes beispiel! an der 'scribble' mfc-demo hab' ich mir damals die zähne ausgebissen, obwohl ich eigentlich dachte, ich hätte die grundlagen von C++ einigermassen verstanden. solche schwierigkeiten hatte ich beim lernen von Java nie...
Gast++ schrieb:
vielmehr glaube ich dass diese fehlerhafte Interpolation der Lernkurve/Erfolgsquote für den größten Teil der Probleme mit Java verantwortlich ist.
welche probleme siehst du (ausser vielleicht geschwindigkeit und speicherbedarf)?
immerhin ist das konzept von Java so überzeugend, dass es selbst der ewige IT-nachzügler-und-trotzdem-monopolist microsoft mit .NET nachgebaut hat.
-
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'.Andererseits kann man nicht so viel Zeit für die Optimierung verwenden, da man ja alles jit machen muss. Aber der Vorteil bei der Optimierung den Java gegenüber C++ hat sind einfach: Keine Pointer. So kann man Aliasing-Probleme etc direkt ausschließen und den Code besser optimieren. Das gilt natürlich für alle Sprachen die keine Pointer haben. Daher ist Fortran zB immer noch sehr beliebt für Berechnungen.
In C99 gibt es ja das Schlüsselwort
restrictum dagegen zu wirken. Ich hoffe mal, dass das in C++0x auch kommen wird.
-
rüdiger schrieb:
So kann man Aliasing-Probleme etc direkt ausschließen und den Code besser optimieren. Das gilt natürlich für alle Sprachen die keine Pointer haben. Daher ist Fortran zB immer noch sehr beliebt für Berechnungen.
Ich denke, die Beliebtheit von Fortran für wissenschaftliche Projekte liegt eher daran, dass dafür irre viel relevanter Code existiert. ...hört man zumindest immer.
-
pale dog schrieb:
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'.Könnte auch am Kursleiter liegen...
über seine Java-kurse sagt er: 'wenn die grösste hürde (OOP, vererbung, etc.) erstmal genommen ist, geht alles recht flüssig.
Könnte auch am Kursleiter liegen...
-
Hi Gregor,
zugegeben, es existiert unheimlich viel Fortrancode bei den Naturwissenschaftlern. Das mag u.a. daran liegen, dass diese seit den 60iger Jahren fast ausschließlich in Fortran programmieren. Wenn auch in Deutschland an den Unis vielerorts Fortran verpönt ist, so wird in den USA, England und Frankreich (die Asiaten, Japan ausgenommen, machen ja jeden Modewitz mit, z.B. Numeric Java) in Mathe, Physik und Ingenieurwissenschaften fast ausschließlich in Fortran programmiert. Die Gründe für das Überleben der alten IBM/Backus Sprache sind recht einfach:-
Fortran ist einfach überzeugend schneller als C/C++ (insbesondere bei Matrizenverarbeitung, wenn Zeiger im Spiel sind) und
-
Fortran ist doch viel viel viel einfacher als c++, trotz Objekt-Fortran (was allerdings kein Physiker anwendet).
Ich selbst beschäftige mich seit knapp einem Jaht mit der Portierung von Fortran-Algorithmen aus dem Gebiet der Astrophysik nach C++, und ich kann die Situation in diesem Bereich recht gut einschätzen. Persönlich bin ich davon überzeugt, dass c++ innovativer als Fortran ist (man bedenke nur, dass viele Physiker immer noch in Fortran 77 programmieren), aber es wird noch mehrere Generationen an Physikern erfordern, bis der Umstieg auf C++ geschafft sein wird.
Java steht hier nicht im Entferntesten zur Disskusion, da für "Massive Computing" absolut ungeeignet (nicht nur wegen der Performance, Java beherrscht ja nicht einmal IEEE-754 Zahlenformate richtig).
Viele Grüße von Tesu
-
-
@tesuji: Interessant: Für Fortran existiert also mehr Code, es ist schneller und einfacher als C++. ...warum portierst Du da was? Was ist die Motivation, die dahinter steckt? Welchen Vorteil bringt C++ da? Für Physiker stellen Programmierfähigkeiten nicht den Hauptteil Ihrer Qualifikation dar. Warum sollten die sich da gerade die komplizierteste Sprache aussuchen? Glaubst Du, dass die Interesse an möglichst elegantem Code haben? Oder benötigen sie unbedingt ein speziellen Feature von C++? Metatemplateprogrammiereung?
Abgesehen davon: Ich glaube, die wenigsten Physiker können etwas mit IEEE-754 anfangen. Die haben wichtigere Dinge zu tun, als sich über solche Dinge Gedanken zu machen.
-
Gregor schrieb:
@tesuji: Interessant: Für Fortran existiert also mehr Code, es ist schneller und einfacher als C++. ...warum portierst Du da was?
frag ich mich auch.
durch'n fortran compiler jagen und zum c++-programm dazulinken wär' wohl der gescheitere weg.
...aber vielleicht baut er auch auch nur eine weitere c++ class library (die die welt nicht braucht).
-
Gast++ schrieb:
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?
AFAIK nein. Es gibt einige Arbeiten von Alexandrescu und von einigen anderen. Aber letztendlich ist die Forschungsarbeit hier noch erstaunlich jung. Hier muss noch viel passieren. Mit ein wenig Glück wird es das aber in nächster Zeit. Allein dadurch, dass C++0x endlich anbietet, Constraints explizit auszuformulieren. Das wird generische Programmierung hoffentlich Mainstream-tauglicher machen.
Gast++ schrieb:
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.
Generische Programmierung ist nicht allmächtig. Genau wie ein Hammer keine Schrauben eindrehen kann, muss man hier die Grenzen kennen: Generische Programmierung (zumindest in der "reinen" Form) ist statisch. Jegliche Art dynamischer Typisierung ist damit also nicht machbar.
Gast++ schrieb:
P.S.: @Konrad Rudolph : Hat das mit dem bitset funktioniert?
Klar.
Allerdings ist der Geschwindigkeitsgewinn im Anwendungsgebiet so gering, dass er praktisch kaum messbar ist. 
-
Gregor schrieb:
Abgesehen davon: Ich glaube, die wenigsten Physiker können etwas mit IEEE-754 anfangen. Die haben wichtigere Dinge zu tun, als sich über solche Dinge Gedanken zu machen.
Das ist glaube ich ein Irrtum. Wenn ich mal mit Physikern über Computing-Lösungen sprach fiel der Begriff immer.
Grüsse
*this
Btw: Zwei Menschen steigen in eine leere Fahrstuhlkabine. Beim nächsten Halt steigen drei aus.
Kommentare zum Phänomen von Experten:Experimentalphysiker: "Messfehler!"
Theoretischer Physiker: "Der Dritte hat sich reingetunnelt!"
Mathematiker: "Nun ja, wenn ein Mensch wieder einstiege wäre die Kabine erneut leer!"
-
Gast++ schrieb:
Btw: Zwei Menschen steigen in eine leere Fahrstuhlkabine. Beim nächsten Halt steigen drei aus.
Kommentare zum Phänomen von Experten:Experimentalphysiker: "Messfehler!"
Theoretischer Physiker: "Der Dritte hat sich reingetunnelt!"
Mathematiker: "Nun ja, wenn ein Mensch wieder einstiege wäre die Kabine erneut leer!"Ich (DER Experte): 9 Monate Fahrzeit, viel Essen und Langeweile.