C++ und Java

[DynamiX]

Wollt mal wissen wie Ihr dazu steht:

In Codingzone.de liefern C++ Progger seeeeeeeeehr überzeugende Argumunte dass C++ besser ist. Könnt ihr mir sagen was (auser plattformunabhängigkeit) gut an Java ist? So langsam glaub ich nämlich auch, dass C++ besser is[/url]

 

[Stefan1200]

Naja, in bestimmten Bereichen ist C++ natürlich die bessere Wahl, da man ohne Kenntnisse in DLL Programmierung (was meist C++ ist) mit Java das Betriebssystem und die Hardware nicht direkt ansprechen kann. Also für Hardware Diagnose Programme, Spiele Trainer (Cheatprogramme) und ähnliche Dinge ist C++ natürlich vorzuziehen.

Andererseits sind viele Dinge wie System Tray unter Windows auch als kostenloses Zusatz für Java verfügbar, wenn man weiss wo, ohne das man gleich C++ lernen muss.

Vorteile von Java sind unter anderem, das man sich nicht um Speicherfreigaben kümmern muss. Auch die Systax ist für Anfänger leicht zu verstehen. Weiterhin muss man sich bei Java nicht umgewöhnen, wenn man GUIs auf anderen Betriebssystemen programmieren möchte. Bei C++ muss unter jedem Betriebssystem die GUI anders programmiert werden.

Das Gegenargument bei Java, das Java sehr langsam sein soll, kann heute nicht mehr so richtig stehen gelassen werden, seit dem Java RE 1.4.1 oder gar 1.4.2. Lediglich das starten von Programmen und teile der Swing Oberfläche sind nicht so performant als in C++. Aber an anderen Stellen traue ich meine Augen nicht, wenn ich meine Java Programme regelrecht fliegen sehe, und fast nicht glauben kann, das dies eine Java Application ist.

 

[mariopetr]

suche nal ne woche lang in c++ nach einem speicherleck. danach wilst du nimmer. ganz zu schweigen von dem deutlich struckturierterem code, den vielen packages, den bussinesextensions, .. . natuerlich wird man mit java so schnell keine treiber oder shooter schreiben, aber dafuer ist ja java auch nicht gedacht.

 

[Hogo]

Warum nicht?
Java ist eine vollständige und komplexe Sprache. Ich wunder mich sowieso, warum sich noch niemand die Mühe gemacht hat ein JOffice oder andere große Programme zu schreiben. Das Manko wird meist auf Swing geschoben, was doch ein wenig hinkt. Aber seit mit Eclipse das SWT gekommen ist, kann man sich über eine flüssige GUI nicht beschweren.
Ausserdem muss an Java doch mehr dran sein, als plattform Unabhängigkeit. Sonst hätte Microsoft ja nicht auf .Net gesetzt, sonder vielleicht auf MC++.

Gruß,

Hogo

 

[stev.glasow]

womit wurde(wird) OpenOffice geschrieben ?

 

[HeyMan]

des weiteren hat java riesen vorteile im web bereich. ein servlet zB wird beim start 1 mal geladen und beansprucht bei gelegenheit den speicher. danke an tomcat servletcontainer.
wie toll zB c/++ cgi's sind muss ich wohl nicht erwähnen. :?

Heyman

 

[AlArenal]

Ausserdem muss an Java doch mehr dran sein, als plattform Unabhängigkeit. Sonst hätte Microsoft ja nicht auf .Net gesetzt, sonder vielleicht auf MC++.

Ich glaube hier liegt ein Verständnisproblem vor. .NET ist keine Programmiersprache, sondern ein Framework. In allen aktuellen Sprachen von MS gibt es Bindings zu .NET, ebenso gibt es diese mittlerweile in Produkten von Mitbewerbern und auch als Open Source.

Wenn ich in .NET in meinen Visual C++ - Anwendungen einsetze, dann werden die dadurch nicht mehr oder weniger plattformunabhängig.

 

[Reality]

womit wurde(wird) OpenOffice geschrieben ?

Achwas, oder? Nur weil es von Sun ist, ist es doch nicht in Java geschrieben. Mit dem gleichen Argument kam ich mal in einem Linuxforum und einer hat mich ausgelacht.

Liebe Grüße
Reality

 

[EagleEye]

womit wurde(wird) OpenOffice geschrieben ?

Achwas, oder? Nur weil es von Sun ist, ist es doch nicht in Java geschrieben. Mit dem gleichen Argument kam ich mal in einem Linuxforum und einer hat mich ausgelacht.

Liebe Grüße
Reality

installiere mal openoffice dann wirste sehn das es in (oder teileweise in java geschrieben ist) weil es um vollständige funktionalität zu haben java braucht

 

[Oxygenic]

Was heißt besser? Besser WOFÜR? Für die Entwicklung von Treibern, realtime-fähiger Software etc. ist Java natürlich nicht zu gebrauchen. Dass sich in dem Bereich noch nicht mal C++ durchgesetzt hat und C noch Standard ist, idt dabei nur ein Detail am Rande. Hier wäre interessant, welche Maßstäbe und Ansprüche an eine Sprache gestellt werden, ansonsten ist jeder Vergleichsversuch sinnlos.

Aber wenn es darum geht, schnell komplexe Applikationen mit GUI (die noch nicht mal plattformunabhängig sein müssen) zu erstellen, dann ist Java ungeschlagen, da kannst du die Pfriemelei mit C++ vergessen. Soll eine GUI noch plattfomunabhängig sein, wird es ganz interessant - was nimmt der C++-Entwickler? WxGadgets? QT? Und neu compilieren muss er es für jede Plattform auch noch.

 

[pogo]

das argument das java langsamer ist zählt nichtmehr.
hab derletzt nen bericht gesehen, indem die geschwindigkeit getestet wurde.
da kan heraus, dass java und c++ gleichschnell sind.

 

[dark_red]

In Codingzone.de liefern C++ Progger seeeeeeeeehr überzeugende Argumunte dass C++ besser ist.[/url]

Überzeugend? Das sieht für mich nach einer Ansammlung von Halbwissen und Vorurteilen von pubertierenden Schülern aus. Wenn wenigstens die C++ basher etwas C++ verstanden hätten, könnte man ja darüber reden. Zudem trollt der Eine nur rum.

Nun ja... es gab schon bessere Diskussionen zum Thema. Mich lässt diese kalt.

So langsam glaub ich nämlich auch, dass C++ besser is

Nun ja... das kann man so nicht stehen lassen. Man sollte sich davon lösen, dass A besser als B (oder umgekehrt). Zudem ist es auch ein wenig wie mit den Äpfeln und Birnen. Meist wird bei dieser Diskussion Java, als Programmiersprache und Technologie (Framework?) mit C++ als reine Programmiersprache verglichen. Dabei wird vergessen, dass ich mit Java-Syntax sehr wohl auch native Programme schreiben kann, so wie ich mit C++ Code auch Bytecode erzeugen kann.

 

[Reality]

Hi,

das argument das java langsamer ist zählt nichtmehr.
hab derletzt nen bericht gesehen, indem die geschwindigkeit getestet wurde.
da kan heraus, dass java und c++ gleichschnell sind.

habe dazu auch einige Tests gelesen, aber die Praxis zeigt bei mir immer etwas anderes.
Egal ob Eclipse, NetBeans oder JBuilder; sie laufen bei mir alle relativ lahm.
Hat jemand schon mal mit Borland C++ Builder oder anderen Compilern/IDEs gearbeitet die mit C++ programmiert wurden? Ein Doppelklick und schon ist das Ding auf. Auch ruckelt bei mir manchmal JBuilder (Garbage Collector?).

Liebe Grüße
Reality

 

[Beni]

Swing war und ist, geradezu unverschämt, langsam. Der Rest von Java ist unterdessen brauchbar schnell geworden, abgesehen vom starten der VM :roll: . Schreib mal ein AWT-Progi...

Und zu Eclipse: 100'000 Icons, Rundungen, mitdenkende Hilfe etc... würde auch in einer anderen Sprache an den Ressourcen zerren.

Die Typen von Codingzone argumentieren mit "haben wir in der Schule gehabt", und, frei übersetzt, "ich will mich nicht anpassen". Naja, finde ich nicht sehr Überzeugend.

Statement zum Schluss:
"der wahrlich gute Programmierer spricht mehrere Sprachen, und entscheidet abhängig der Aufgabe, welche Sprache geeignet ist."

mfg Beni

 

[Grizzly]

[...]Statement zum Schluss:
"der wahrlich gute Programmierer spricht mehrere Sprachen, und entscheidet abhängig der Aufgabe, welche Sprache geeignet ist."

mfg Beni

Dem stimme ich zu.

 

[dark_red]

Hat jemand schon mal mit Borland C++ Builder

Du meinst den C++BuilderX? Mit was wurde der nochmal programmiert?

SCNR (und ja... sehr provokativ )


btw... das Ding ist wirklich schneller als andere Swing-Anwendungen. Dafür dass es eine Swing-Anwendung ist, ist es wirlich erstaunlich schnell, trotz der komplexität. Zum Starten braucht es auch "nur" in etwa gleich viel Zeit, wie die "classic" C++Builder (jaja... ich programmiere auch C++ :bae: ). Ich würde sagen, es ist trotzdem leicht träger, aber das liegt in einem Bereich, in dem es kaum spürbar ist.

btw2... ich finde die Idee mit dem C++ Builder X eigentlich super von Borland. Wieder einmal etwas Neues (Cross-Plattform C++, inkl wxWidgets für die GUI usw. ). Allerdings finde ich Borland auch nicht so toll. Habe letzhin einen sehr schlechten Eclipse/JBuilder vergleich von Borland gelesen (Eclipse soll eine unsichere rechtliche Lage haben - da Open Source - und Borland gibt als "Beleg" den SCO-IBM(Linux)-Konflikt an).

 

[Reality]

Hi,

Hat jemand schon mal mit Borland C++ Builder

Du meinst den C++BuilderX? Mit was wurde der nochmal programmiert?

ich habe nur den 5er und da flitzt er.
Mit was wurde C++ Builder X geschrieben?

Ausserdem ist es ziemlich oberflächlich zu sagen, dass Java gleich schnell ist wie C++, denn es existieren sehr viele C++ Compiler und alle sind unterschiedlich schnell! Der von MS ist z.B. einiges schneller als der von Borland.

Ich kann mich übrigens Beni anschliessen. Ein richtig guter Programmierer kann mehrere Sprachen *noch viel vor mir hab*.

Liebe Grüße
Reality

 

[dark_red]

hehe... Ich habe ja nie behauptet, dass Java und C++ gleich schnell sind. Für nähere informationen über meine Meinung, einfach meinen ersten Post in diesem Thread konsultieren...

Den C++Builder X hat Borland ironischerweise in Java geschrieben. Ist mehr oder weniger die selbe Oberfläche, wie vom JBuilder 9.

C++BuilderX Download / Demo (Flash)

 

[Reality]

Kannst du mir verraten, wie man in Java seine Programme in Binärcode compilieren kann? Möchte ich mal ausprobieren.

Liebe Grüße
Reality

 

[Roar]

Kannst du mir verraten, wie man in Java seine Programme in Binärcode compilieren kann? Möchte ich mal ausprobieren.

gar nicht. Java bleibt Java und Bytecode bleibt Bytecode. Ansonsten wär das ja völlig unsinnig.

 

[Reality]

Auf der ersten Seite schrieb er folgendes:

Dabei wird vergessen, dass ich mit Java-Syntax sehr wohl auch native Programme schreiben kann, so wie ich mit C++ Code auch Bytecode erzeugen kann.

Ich bin mal so offen und glaube ihm das. Mich würde interessieren wie (ohne JNI versteht sich).

Liebe Grüße
Reality

 

[dark_re]

der gcj aus der GCC kann dies zum beispiel. ist allerdings meist eine bastellei. gibt ein paar verrückte, die sich eclipse mal so übersetzt haben. in der tat ist das ein wenig ketzerei.

zu c++ bytcode hatte ich auch einmal einen link. allerdings war das kein java bytecode, sondern ein eigener, der auch eine eigene vm vorausgesetzt hat. leider ist der link verloren gegangen...

ob das in der praxis gebräuchlich ist, ist nicht so wichtig. es ging mir darum, dass nicht äpfel mit birnen verglichen werden. (oder apfel mit apfelsaft )

 

[Oxygenic]

Kannst du mir verraten, wie man in Java seine Programme in Binärcode compilieren kann? Möchte ich mal ausprobieren.

gar nicht. Java bleibt Java und Bytecode bleibt Bytecode. Ansonsten wär das ja völlig unsinnig.

Stimmt zwar nicht, aber macht ja nix.

Es gibt Compiler, die Executeables aus Bytecode erzeugen. IBM hat/hatte mal einen. Ein anderer Vertreter kommt von Excelsior und heißt Jet. Allerdings ist der Name irreführend, die Compilezeit ist gewaltig, und die resultierenden Executeables sind monströs. Nicht zu gebrauchen also.

 

[ZeusOfCrete]

Hallo zusammen,

eine Programmiersprache grundsätzlich in
"besser oder schlechter als..." einzustufen, führt
meistens nicht weit.

Sicher ist: Die Java - Performance ist besser, als ihr Ruf !

Viele Grüße

Zeus

http://www.kano.net/javabench/
http://www.golem.de/0406/31579.html

 

[Dr. Morv]

Man kann eine Programmiersprache gar nicht einordnen, da "mehr Möglichkeiten" ja oft "mehr Arbeit für den Progger" heißt. Es kommt also nur darauf an, wonach man geht. Übrigens ist es für mich schon relevant, ob ich mit einer Programmiersprache eine Exe erzeugen kann. Da ist z.B. QBasic besser als Java, denn mit QuickBasic 4.5 kann man exes erstellen. Aber keiner würde ernst haft behaupten, Basic sei deswegen allgemein besser als Java. Ich denke, C++ lässt einem mehr Dinge auf eigene Verantwortung tun. Dafür kann man auch gemeine Fehler machen wie das zugreifen auf Arrayindizes, die es gar nicht mehr gibt. Dafür hat Java einfachere Multimediamöglichkeiten, aber sehr viele Klassen, die zum Teil recht sinnlos sind (ich darf an den Media Tracker erinnern).

 

[Grizzly]

[...]Dafür hat Java einfachere Multimediamöglichkeiten, aber sehr viele Klassen, die zum Teil recht sinnlos sind (ich darf an den Media Tracker erinnern).

Ist der MediaTracker nicht zum Prüfen, ob ein Bild vollständig geladen wurde? ???:L

 

[Roar]

@grizzla: ehm, ja eigentlich schon.

@morv: das argument mit den executables is ja wohl n witz ("argument" ist vielleicht falsch. relevanz, wie du sagtest). das is doch nur ne windumm.explorer-nutzer-end-user-bequemlichkeit. und da java plattformunabhängig ist und zudem zu großen teilen auch andere einsatzgebiete als den desktop hat sind executables bei java fehl am platz :-/

gruß
Roar, der auch JSmooth benutzt

 

[L-ectron-X]

[...]Dafür hat Java einfachere Multimediamöglichkeiten, aber sehr viele Klassen, die zum Teil recht sinnlos sind (ich darf an den Media Tracker erinnern).

Ist der MediaTracker nicht zum Prüfen, ob ein Bild vollständig geladen wurde? ???:L

Nicht nur, er dient zum Vorladen (cachen) derzeit nur von Grafikdateien.
Schreibe mal ein Grafik lastiges Applet ohne MediaTracker, dann siehst Du den Unterschied.
Demzufolge würde ich nicht sagen, dass die Klasse MediaTracker "recht sinnlos" ist.

Und außerdem: Wozu exe-Dateien? Es gibt jar-Dateien, die ähnliches leisten.
Wenn man exe-Dateien publiziert, braucht man immer noch ein JRE.

 

[Grizzly]

Wenn man es sehr abstrakt sieht, hat ein Windows Executable (eine stink normale Anwendung, kein Treiber o.ä.) auch ein JRE bzw. läuft unter einem. Windows stellt dabei die Sandbox dar. Dabei wird der Byte-Code zu einem großen Teil direkt auf dem Prozessor ausgeführt. Und die Windows API entspricht den Java Klassen.
Da aber, wie gesagt, die Byte-Code direkt ausgeführt wird, können Windows Programm nicht unabhängig von der Systemarchitektur ausgeführt werden.

 

[0xdeadbeef]

Habe mich jetzt einige Zeit mit Java beschäftigt und werde es auch weiterhin tun, aber es gibt doch einige Dinge, die ich in Java nicht so toll finde:

1) Keine Destruktoren: in C++ kann man seine Klasse sauber abschließen (Handles zurückgeben usw.), indem man diese nötigen Aufräumarbeiten im Destruktor erledigt. In Java gibt es nur die Methode "finalize()", deren Aufruf aber irgendwann mal passiert, wenn die Garbage Collection die Klasse tatsächlich löscht.

2) Die unterschiedliche Behandlung von Basistypen und Objekten ist einigermaßen eigentümlich. Speziell bei der Übergabe als als Parameter wird zwar in beiden Fällen "copy by value" benutzt, weil Objekte in Java aber immer Referenzen sind, bekommt man immer eine Referenz auf ein Objekt, aber niemals auf einen Basistyp. Insofern kann man auch nicht ohne weiteres mehr als einen Basistyp zurückgeben, dazu muß man wieder ein Container-Objekt benutzen. Wesentlich schöner wäre eine gleichartige Behandlung von Basistypen/Objekten und die manuelle Auswahl zwischen "by value" und "by reference" gewesen.

3) Das gleiche Problem dehnt sich auf den Zuweisungsoperator "=" und die Vergleichoperatoren "==" usw. aus. Die Zuweisung von Referenzen mag machnaml noch sinnvoll sein, der Vergleich von Referenzen (speziell >= usw.) ist das aber kaum jemals. Hier merkt man halt, daß das Überladen von Operatoren doch ein interessantes Sprachmerkmal ist, auch wenn es die wenigsten C++-Programmieren selsber benutzen: zumindest für die Bibliotheksfunktionen trägt Operatorenüberladung aber viel zur Eleganz einer Sprache bei.

4) Ich finde es extrem eigenartig, daß es keine unsigned Integertypen gibt. Zudem sind einige der Erweiterungsregeln äußert merkwürdig (byte + byte = int).

5) In Java ist man noch viel stärker als in C++ genötigt, ständig Instanzen zu erzeugen und wieder zu zerstören. Man könnte sogar sagen, daß die inflationäre temporäre Erzeugung von Objekten ein Sprachmerkmal ist. Zum einen gibt es keine einfache/standardisierte Methode, den Inhalt von Objekten zu kopieren, zum anderen benutzen einige Sprachmerkmale diese Features intensiv ("+"-Operator von String erzeugt temporäre Stringbuffer, Wrapperklassen usw.). Ich würde mal die Behauptung wagen, daß diese extrem hohe Frequenz der Objekterzeugung in Java-Programmen (Allokierung + Konstruktor-Aufruf!) großteils für die eher geringe Perfomanz vieler Java-Anwendungen verantwortlich ist.

6) Wrapperklassen sind ziemlich häßliches Design und kosten u.U. auch ziemlich Performanz. Z.B. wenn man Basistypen in einem Vektor o.ä. speichern will.

7) Bis Java1.5 gibt es keine typsicheren Containerklassen. Auch die nun eingeführten Generics sind offensichtlich nicht in jedem erdenklichen Fall 100% typsicher zur Compilezeit.

8 ) Daß man auf die Registry usw. nicht zugreifen kann, ist ja verständlich, aber warum braucht man bereits für Zugriffe auf die serielle Schnittstelle native DLLs, wenn doch auch Sockets platttformübergreifend implementiert sind? Von USB usw. ganz zu schweigen...

9) Zumindest bis v1.5 ist eine variable Anzahl von Parametern möglich, womit z.B. eine Funktion wie "printf" unmöglich ist. Wurde eventuell jetzt geändert, aber sicher bin ich mir jetzt auch nicht.


Es gibt allerdings auch eine Menge Sachen, die mir in C++ nicht so toll gefallen.

 

[Illuvatar]

1) Und was willst du in Java bitte in einen Destruktor schreiben, wenn alles automatisch aufgeräumt wird? Ich hab noch nie einen gebraucht.
2) Tja eine nichtprimitive Variable enthält halt immer die Speicheradresse, und wenn die kopiert bzw. verglichen wird, hat das eben nix mit dem Inhalt zu tun. Auch meiner Meinung nach ist es eine Schwachstelle von Java, dass es nicht rein objektorientiert wird, allerdings ist es immernoch besser als C++. Vorteil für C# (bzw .NET), wo alles objektorientiert ist, und mit dem Parameter ref "by value" übergeben werden kann.
3) Nunja die fehlende Operatorüberladung kann man positiv und negativ sehen, sinnvoll eingesetzt, ist es sicher gut. Aber: wofür gibt es Object#equals, dass man überschreiben kann? Das macht ja dann auch kein Unterschied mehr zu einem Operator.
4) Hm... wusste ich gar net, stimmt aber, könnte auch short sein, was besser wäre.
5) Juchu... zurück zur prozeduralen Programmierung! Wenn man so blöd ist, zigmal Stringconcatenation zu benutzen statt nem StringBuffer, dann ist das sein Problem.
6) Naja, Autoboxing in Java5 is ja schonmal was. Sonst siehe 2.
7) Ach, wann nicht?
8) Naja, es gibt javax.comm (das kann man bei sun.com runterladen), das ist aber auch nicht für alles die Lösung. Dafür ist Java plattformunabhängig.
9) Und was ist dann OutputStream#printf (String, Object...) ?

 

[Reality]

Ist ja echt schlimm was die da schreiben...
http://board.codingzone.de/viewtopic.php?t=146&start=0&sid=280b2f535a514f67d8db47c2b941a799

 

[Beni]

Ja. *Halbwissen (bzw. gar-nicht-Wissen) gepaart mit einer vorgefassten Meinung... ist leider in allen Foren und in allen Threads so, in deren Titel Java und C++ vorkommt.

(*z.B. über Dinge wie OOP, verschiedene Lösungswege, Syntax der Sprachen...)

 

[bummerland]

Ist ja echt schlimm was die da schreiben...
http://board.codingzone.de/viewtopic.php?t=146&start=0&sid=280b2f535a514f67d8db47c2b941a799

alter, nee du... das ist ja echt schlimm, was die da schreiben... :bahnhof:

 

[0xdeadbeef]

@Illuvatar:

zu 1) Die Garbage Collection gibt nur Speicher frei, aber keine Handles für Files usw. In kleinen Programmen ist das üblicherweise kein Problem, aber in großen Projekten kann es zu einem werden. Da ist die Methode über den Destruktor einfach wesentlich schöner, zumal sie ja auch im Fehlerfall funktioniert.

zu 3) equals wirkt nur auf Object -> nicht typsicher und man braucht einen cast. Außerdem ist "==" einfach griffiger und ja auch inkonsequenterweise korrekt bei den Basistypen.

zu 5) War ja nur ein Beispiel und ich bin mir der Probleme durchaus bewußt. Trotzdem kann man nicht leugnen, daß Java einen hier und dort zum Anlegen temporärer Objekte verleitet (clone und so).

zu 6) Nur oberflächlich. Der erzeugte Bytecode ist der gleiche.

zu 7) Es gibt dazu einige Diskussionen in den Java.sun.com-Foren. Ich wage es mir nicht, ein Urteil zu bilden, aber es scheint ein Compiler-Bug zu sein:
http://forum.java.sun.com/thread.jsp?forum=316&thread=563260&tstart=0&trange=15

zu 8 ) Ich weiß, aber es existieren nur native (!) Versionen für Win32 und Solaris. Selbst die Linux-Version ist von einem Privatmann portiert (empirisch, da es keinen Quellcode gibt, zudem nur der UART-Teil und nicht der Parallelport). Außerdem scheint mir das ganze etwas buggy. Z.B. werden mehrere der von der Hardware angebotenen Baudraten nicht korrekt unterstützt. Last but not least hat javax.comm eine sehr merkwürdige Methode, seine ini-Datei zu finden, die auch nicht korrekt dokumentiert ist. Mußte die API dekompilieren, um das in den Griff zu kriegen

zu 9) Ich sagte ja, ich habe da was im Hinterkopf, daß es in der 1.5 dazugekommen ist. Ist allerdings die Klasse PrintWriter, nicht OutputStream. Und ist halt auch ein bisserl spät, genauso wie die Generics.

 

[stev.glasow]

Ist ja echt schlimm was die da schreiben...
http://board.codingzone.de/viewtopic.php?t=146&start=0&sid=280b2f535a514f67d8db47c2b941a799

alter, nee du... das ist ja echt schlimm, was die da schreiben... :bahnhof:

Wundert dich das noch? Zeig mir eine Seite zu diesem Thema bei der beiderseits kein Mist verzapft wird. Oft gehen die Argumente doch nie über Performance, Platfomabhängigkeit und Syntax hinaus.

 

[0xdeadbeef]

@steveq:
Na das sind halt auch die interessantesten Punkte. Das Problem ist halt oft, daß niemand wirklich beide Sprache _intensiv_ programmiert hat. Außerdem hat man halt seine (teils ideologischen) Präferenzen.

Mit zum Beispiel gehen alle Sprachen gegen den Strich, die kein ";" zum Trennen von Befehlen kennen und/oder sich auf die Einrückung anstelle von Klammern verlassen. Egal ob VB, Ruby oder Python: mit diesen Sprachen werde ich einfach nicht warm
Das ist zwar "nur" Syntax, aber für mich persönlich reicht das manchmal schon.

 

[Grizzly]

[...]
8 ) Daß man auf die Registry usw. nicht zugreifen kann, ist ja verständlich, aber warum braucht man bereits für Zugriffe auf die serielle Schnittstelle native DLLs, wenn doch auch Sockets platttformübergreifend implementiert sind? Von USB usw. ganz zu schweigen...
[...]

Das Sockets drin sind, die serielle Schnittstelle sowie USB aber hingegen nicht, ist mir klar. Wenn ich bspw. eine Verbindung zu einem Server im Internet aufbauen möchte, kann ich eigentlich nur über die Sockets gehen. Dabei ist es mir aber relative egal, ob das TCP/IP Paket nachher über die Netzwerkkarte zum Server wandert oder über das an der seriellen Schnittstelle oder am USB angeschlossenen Modem.
Und wenn ich bspw. auf einen USB Stick zugreifen möchte, werde ich das ja auch eher über den Laufwerksbuchstaben bzw. der Mount Point, und nicht direkt.

Es gibt nur ganz wenige Fälle, in denen man den direkten Zugriff braucht. Und in diesen wenigen Fällen braucht man dann halt entweder zusätzliche Bibliotheken oder JNI.

Mir persönlich gefällt an Java einige Teile der API nicht. Sun hällt sich teilweise dabei nicht an die eigenen Design-Empfehlungen. Am schlimmsten ist dabei die Swing - auch unter der Haube.

Java ist momentan mein Leib und Magen Programmiersprache - auch wenn da einige Macken und Probleme sind.

 

[0xdeadbeef]

@Grizzly:
Naja, "javax.comm" zeigt ja, wie man die serielle/parallele Kommunikation sauber kapseln kann. Daß das Anfordern einer Baudrate oder das Senden von ein paar Bytes dann in irgendwelchen HW-Registern endet, ist ja gar auf der Interface-Ebene gar nicht sichtbar.
Mir ist irgendwie nicht so transparent, warum das ein so großer Unterschied zur Ausgabe von Musik, Grafiken oder TCP-IP Kommandos sein soll. Ich würde auch mal annehmen, daß USB ab einer bestimmten Protokollebene (ebenfalls) völlig von der Hardware abstrahierbar ist.
Deshalb gestatte ich mit den Luxus, diese Dinge weiterhin als Lücken in der (ansonsten ja sehr umfassenden) Klassenbibliothek zu sehen.

Ich muß Dir aber zustimmen, daß die teils sehr inkonsistente API ebenfalls ärgerlich ist. Auch schon ganz fundamentale Dinge wie: Array.length" (Attribut) aber "String.length()" (Methode) und Vector.size() unterscheiden sich.

Ich wäre auch froh gewesen, wenn man bei der Sprachdefinition mehr Mut gehabt hätte, sich von C/C++ abzusetzen: beispielsweise finde ich die 1:1-Übernahme des häßlichen Switch-Case-Konstrukts bedauerlich. Wenigstens ein "fallthrough" Keyword anstelle des "break" wäre schonmal ein Ansatz gewesen, denn der Normalfall in einem Switch-Case ist ja aus Sicht eines Programmieres das Verlassen des Cases nicht das Weiterlaufen in den nächsten Case.

Aber um mal ein paar positive Dinge zu nennen: was ich an Java besonders schätze (in keiner besonderen Reihenfolge):

1) Javadoc (ok, unter C++ kann man Doxygen oder so einsetzen, aber es ist halt kein Bestandteil der C++-Kultur)
2) Die mächtige Stringklasse (reguläre Ausdrücke und so. während sich die C++-Fraktion zwischen verschiedene Stringklassen zerfleischt MFC/STL usw.).
3) Die mächtige und relativ zukunfstsichere Swing/JFC-API (während man ansonsten selbst auf einer Plattform den Launen des Anbieters folgen muß).
4) Die IMHO saubere - wenn auch striktere - Behandlung von Exceptions (Klassenhierarchie, während man in C++ irgendwas als Exception benutzen kann).
5) Das integrierte Threadmodell (mir ist unerklärlich, wie man in C++ nach wie vor nur single.threaded Anwendungen in der Norm unterstützen kann)
6) Die Verfügbarkeit großartiger freier Entwicklungstools wie Eclipse und Netbeans
7) Die Mögllichkeit zur Entwicklung von Anwendungen, Applets, Midlets und Servlets mit einer Sprache und ähnlichen Klassenbibliotheken.
8 ) Die sehr gute Unicode-Unterstützung und Lokalisierungsfunktionen.
9) Feste Größe von int usw. (ein stetiges Ärgernis unter C/C++)
10) Explizite Kurzschlußoperatoren (in C teils implementierungsabhängig) und explizites logisches Xor (fehlt in C(++))
11) Seht guter Compiler, der große Teile der Funktionalität hat, die man für C mit PCLint o.ä. dazukaufen muß.
12) Der Einsatz von Labeln bei continue/break ist eine interessante Lösung als Goto-Ersatz (Verlassen von mehreren Schleifenkörpern auf einmal etc.)
13) Daß Arrays Objekte sind, mag zwar etwas Performance kosten, ist aber sehr elegant (length, Indexprüfung usw.).
14) Weil if (und dergleichen) nur boolsche Ausdrücke zuläßt, sind klassische Zuweisungsfehler nicht möglich ( "if (a=3) {}" ).

 

[Grizzly]

@Grizzly:
Naja, "javax.comm" zeigt ja, wie man die serielle/parallele Kommunikation sauber kapseln kann. Daß das Anfordern einer Baudrate oder das Senden von ein paar Bytes dann in irgendwelchen HW-Registern endet, ist ja gar auf der Interface-Ebene gar nicht sichtbar.
Mir ist irgendwie nicht so transparent, warum das ein so großer Unterschied zur Ausgabe von Musik, Grafiken oder TCP-IP Kommandos sein soll. Ich würde auch mal annehmen, daß USB ab einer bestimmten Protokollebene (ebenfalls) völlig von der Hardware abstrahierbar ist.
Deshalb gestatte ich mit den Luxus, diese Dinge weiterhin als Lücken in der (ansonsten ja sehr umfassenden) Klassenbibliothek zu sehen.[...]

Normalerweise spricht man aber nicht die Hardware an der seriellen Schnittstelle an, sondern eher dessen Funktionalität. Bspw. spreche ich bei einem Modem an der seriellen Schnittstelle meist nicht das Modem an, sondern baue eine Verbindung über TCP/IP, das per PPP über die Modem-Verbindung geschickt wird, auf. Bei Druckern an der seriellen/parallelen Schnittstelle gilt ähnliches: Ich spreche den Drucker nicht direkt an, sondern drucke ganz einfach. Der Rest muss vom Betriebssystem und dem Druckertreiber erledigt werden.

Was ich aber nicht ganz verstehe, ist, warum Sun nicht entsprechende Zusatzbibliotheken anbietet. Ich meine, es muss ja nicht im JRE/JDK landen - die meisten Anwendungen brauchen das ja eh nicht - aber optional wäre nett. Wer sich jedoch mal mit der Java Communication API rumgeschlagen hat, weiss, dass die aus dem letzten Jahrtausend stammt (hey, das stimmt sogar ) und außerdem offiziell nur für Windows und Solaris erhältlich ist (es gibt auch einen Workaround für Linux - Java Comm Serial API How-To for Linux - ist aber halt nur ein Workaround und keine echte Unterstützung).
Es wäre eine super Sache, wenn Sun diese Bibliotheken auch anbieten und vor allem pflegen würde.

[...]14) Weil if (und dergleichen) nur boolsche Ausdrücke zuläßt, sind klassische Zuweisungsfehler nicht möglich ( "if (a=3) {}" ).

Das stimmt aber auch nur in Deinem Beispiel. Wenn ich bspw. boolean in der Klammer zuweise

boolean a = false;
boolean b = true;
if (a = b) { }

funktioniert das Ganze schon nicht mehr.

 

[bummerland]

Ist ja echt schlimm was die da schreiben...
http://board.codingzone.de/viewtopic.php?t=146&start=0&sid=280b2f535a514f67d8db47c2b941a799

Hab die Diskussion da noch mal angestachelt... hehe :wink:

 

[stev.glasow]

Ist ja echt schlimm was die da schreiben...
http://board.codingzone.de/viewtopic.php?t=146&start=0&sid=280b2f535a514f67d8db47c2b941a799

Hab die Diskussion da noch mal angestachelt... hehe :wink:

Hehe. Einiges läuft nämlich echt schneller (hab ich mir sagen lassen ). Aber durch einige Performanceschwierigkeiten von Swing hat Java seinen Ruf weg.
Mit diesem C++ Code wäre ich aber vorsichtig: bist du dir sicher, dass das nicht doch schneller zu realisieren ist?

 

[DesertFox]

Wenn ja, dann können es doch sicher die "c++ Profis", die doch so toll für C++ argumentieren und auch dann sicher so toll proggen können, das sicher gut verbessern

 

[0xdeadbeef]

Ich würde mal behaupten, es ist sehr, sehr unwahrscheinlich, daß optimaler Java-Code schneller als optimaler C++-Code ist. Es ist aber sicher so, daß gerade bei Operationen mit Basistypen in engen Schleifen Java dank JIT usw. nicht wesentlich langsamer ist als C++.
Das Problem ist immer, was man genau mit was vergleicht. Bereits die diversen Visual-C++-Compiler erzeugen beim gleichen Quellcode teils Programme mit massiv unterschiedlicher Performance. Gerade die neueren Visual-C++-Compiler haben nochmal eine teils dramatisch bessere Optimierung.
Wenn man dann einigermaßen optimalen Java-Code mit ungeschickt implementiertem C++-Code auf einem älteren Compiler vergleicht, mag ein Java-Programm sogar schneller sein. Für eine Pauschalaussage ist das aber sicherlich nicht ausreichend.

 

[helium]

Vorteile von Java sind unter anderem, das man sich nicht um Speicherfreigaben kümmern muss.

Naja, C++-Programmierer kennen sogenannte Smart-Poitner, mit denen die Speicherfreigabe voll automatisch statfidnet. Außerdem gibt es auch GC-Bibliotheken. Da man den new-Operator überladen kann könnte man sogar per Klasse entscheiden, wie sie am besten handzuhaben ist.
In der Regel wird aber auf den ganzen aufwand verzichtet und einfach Konsequent Smart-Pointer eingesetzt.

Die unterschiedliche Behandlung von Basistypen und Objekten ist einigermaßen eigentümlich. Speziell bei der Übergabe als als Parameter wird zwar in beiden Fällen "copy by value" benutzt, weil Objekte in Java aber immer Referenzen sind, bekommt man immer eine Referenz auf ein Objekt, aber niemals auf einen Basistyp. Insofern kann man auch nicht ohne weiteres mehr als einen Basistyp zurückgeben, dazu muß man wieder ein Container-Objekt benutzen. Wesentlich schöner wäre eine gleichartige Behandlung von Basistypen/Objekten und die manuelle Auswahl zwischen "by value" und "by reference" gewesen.

Naja, es gibt nunmal wertartige und referenzartige Objekte. Du kannst zwei Autos haben, beide vom selben Modell, selbes Baujahr, selbe Farbe, ... alles gleich und dennoch sind es zwei verschiedene Autos. Das sind eben Identitäs-Objekte, also refernzartige Objekte. Bei anderen Dingen ist das anders. Egal wie oft du die Zahl 3 an verschiedenen Stellen speicherst es ist immer ein und die selbe Zahl 3. Das ist ein wertartiges Objekt. C# gibt einem mit class und struct die Möglichkeit beides perfekt zu modelieren, Java verzichtet darauf, da der größte Teil der in der Softwareentwicklung vorkommenden Objekte referenzartig ist.

Ich finde es extrem eigenartig, daß es keine unsigned Integertypen gibt. Zudem sind einige der Erweiterungsregeln äußert merkwürdig (byte + byte = int).

Tja, da sieht man mal wieder, was Java alles von C übernommen hat.

Und was willst du in Java bitte in einen Destruktor schreiben, wenn alles automatisch aufgeräumt wird? Ich hab noch nie einen gebraucht.

Immer wenn du merkst, das du ein finally brauchst, um etwas garantiert aufzuräumen. RAII ist ein tolles konzept, was dem Programmierer viel Arbeit abnimmt und den Code zudem übersichtlicher hält.

Nunja die fehlende Operatorüberladung kann man positiv und negativ sehen, sinnvoll eingesetzt, ist es sicher gut. Aber: wofür gibt es Object#equals, dass man überschreiben kann? Das macht ja dann auch kein Unterschied mehr zu einem Operator.

Naja, da gibt's immernoch die Möglichkeit, dass das Objekt null ist. Zudem sind Operatoren deutlich übersichtlicher.

14) Weil if (und dergleichen) nur boolsche Ausdrücke zuläßt, sind klassische Zuweisungsfehler nicht möglich ( "if (a=3) {}" ).

Ach. Schreib mal in einem D-Programm

if (a=3) {}

und du wirst einen Fehler erhalten, weil du innerhalb der Bedingung versuchst zuzuweisen. Schreibst du hingegen

if (3) {}

ist das vollkommen legal, weil integrale Werte als Wahrheitswerte gesehen werden. Es geht also auch anders. Und Java hat immernoch das Problem, das man boolsche Werte zuweisen kann, was in D logischerweise nicht geht.


Ich will Java keinesfalls schelcht machen, aber die Sprache an sich ist doch eher schwach. Dafür hat Java eine erstklassige Bibliothek!

 

[0xdeadbeef]

Ich finde es extrem eigenartig, daß es keine unsigned Integertypen gibt. Zudem sind einige der Erweiterungsregeln äußert merkwürdig (byte + byte = int).

Tja, da sieht man mal wieder, was Java alles von C übernommen hat.

Nein das ist in C/C++ definitiv nicht so...

14) Weil if (und dergleichen) nur boolsche Ausdrücke zuläßt, sind klassische Zuweisungsfehler nicht möglich ( "if (a=3) {}" ).

Ach. Schreib mal in einem D-Programm

if (a=3) {}

und du wirst einen Fehler erhalten, weil du innerhalb der Bedingung versuchst zuzuweisen. Schreibst du hingegen

if (3) {}

ist das vollkommen legal, weil integrale Werte als Wahrheitswerte gesehen werden. Es geht also auch anders. Und Java hat immernoch das Problem, das man boolsche Werte zuweisen kann, was in D logischerweise nicht geht.

Ich programmiere kein "D". Ich habe von C/C++ gesprochen und da stimmt meine Behauptung. Daß der "Schutz" in Java für boolesche Typen nicht funktioniert, ist auch klar, aber zu 99% vergleicht man ja Zahlenwerte und da tut es.

 

[helium]

sigend char + sigend char = int

auch wenn du z.B. ein char an eine elipsis-Funktion übergibtst (...) wird daraus ein int.

Ich programmiere kein "D". Ich habe von C/C++ gesprochen und da stimmt meine Behauptung.

Dagegen habe ich nie etwas gesagt. Ich habe lediglich eine Sprache aufgeführt, die eine dritte Möglichkeit verwendet.

Ich weiß nicht viel über C++, aber ich denke das Java (SE) einfacher (und schneller) zu erlernen und handhaben ist, konkret kann ich nicht werden, ist nur so'n Eindruck den ich habe.

Wenn es nur um die Sprache an sich geht, hast du eindeutig recht. Java ist schneller und einfacher erlernbar. Allerdings musst du dich in jeder OO-Sprache mit Dingen wie Design-Pattern, etc. auseinandersetzen.

 

[0xdeadbeef]

sigend char + sigend char = int

auch wenn du z.B. ein char an eine elipsis-Funktion übergibtst (...) wird daraus ein int.

Das ist richtig, "byte" ist aber unsigned und wird AFAIK in C nicht automatisch erweitert.

 

[n0n3]

Mir hat mal jemand gesagt dass Java in C++ programmiert ist ... irgendso ein C++ Fanatiker das stimmt doch nicht oder? ???:L
Abgesehen davon meint er dass Java uneffizient sei ... und umständlich ... und ein Pleitegeier ...

 

[AlArenal]

Die Java VM ist in C/C++ programmiert. Den Rest kommentiere ich nicht, weil das polemisches undifferenziertes Gefasel ist. Das würde zu nichts führen.

In was hattest du denn gedacht, dass die VM entwickelt ist?

Java hat einige sehr interessante Konzepte aus Smalltalk übernommen, andere hat es etwas verwischt, andere ganz beiseite gelassen. Nehmen wir z.B. mal Squeak als Smalltalk-Vertreter, findet man schnell heraus, dass auch die komplette VM in Smalltalk entwickelt ist. Naja, C++ ist ja auch C++ und kein pures Eiffel