Unterschied JAVA & C++

Markus94 schrieb:
> Bei C++ ist es mir klar wie ein Programm aufgebaut ist.

scheinbar nicht. Auch C++ Programm brauchen eine Main Funktion.

Arduino versteckt dir viele Dinge, die man aber wissen wollte man glaubt 
eine Sprache zu kennen.

Markus94 schrieb:
> Bei C++ ist es mir klar wie ein Programm aufgebaut ist.
>
> Zb
>
> int Led =13;
>
> void Setup()
> {
> pinMode(Led,OUTPUT);}
>
> void Loop()
> {
> digitalWrite(Led,HIGH)}

Aber nur in Arduino, normal hat man eine main, dann würde dein Besipiel 
so ausshen:

1

int Led =13;

2

3

int main(void)

4

{

5

  pinMode(Led,OUTPUT);

6

  while(1)

7

  {

8

    digitalWrite(Led,HIGH)

9

  }

10

  return 0;

11

}

Google mal nach:
"java ist auch eine Insel"
Ist ein Onlinebuch, aber vorsicht, so richtig eins wo man noch selbst 
lesen muss und nicht bunte Filmchen vorgespielt kriegt in denen einer 
cool rumhüpft, triviale Beispiele zeigt und dir erzählt wie toll das 
alles ist.

Andreas S. schrieb:
> Das Buch gibt es außerdem auf totem Baum.

Ich weiss, aber ich denke damit hätte ich den TO völlig überlastet, 
zumal es auch noch so ein dicker Wälzer ist und -igitt- nicht kostenlos.
Sorry wegen der Ironie, ist nicht gegen dich, Andreas :-)

Dennis H. schrieb:
> Erzeugt die Laufzeitumgebung von Java dann kein Objekt der Klasse in
> welcher die public static void main(String[]args) definiert ist ?

Warum sollte sie? Die Klasse wird nirgendwo instanziert und main ist 
static.

Dennis H. schrieb:
> Auf Mitglieder der Klasse die nicht static sind hätte die main ja eh
> keinen Zugriff ?

Richtig.

Der Unterschied zwischen JAVA und C++ ist erstmal das in JAVA es keine 
mehrfachvererbungen gibt.
Alle Dateien eines JAVA Programs sind jeweils Klassen.
Arduino benutzt zwar C++ um die Bibliotheken zu machen ist aber eher was 
selbstgestricktes.
Schau mal z.B. das JAVA-Tutorial duch:
http://docs.oracle.com/javase/tutorial/java/TOC.html
Bei C++ hast Du neben mehrfacher Vererbung auch kein Runtimecontainer, 
d.h. während bei JAVA ein NULLPOINTER abgefangen wird kannst Du mit C++ 
den Rechner zerschießen.
Hier mal ein C++ Tutorial:
http://www.cpp-tutor.de/cpp/hinweise.html
Beides sind OOP und haben mächtige Bibliotheken.
Ich persönlich würde QT und C++ JAVA vorziehen, beides ist Plattform 
unabhängig aber C++ nativ ist deutlich schneller als JAVA.
Lies Dir die Tutorials durch und entscheide dann was Du nehmen willst.
Um OO lernen kommst Du bei beiden nicht herum !

kalterkaffee schrieb:
> Der Unterschied zwischen JAVA und C++ ist erstmal das in JAVA es
> keine
> mehrfachvererbungen gibt.
Wenn das für dich der Hauptunterschied ist, kennst du nicht viel von 
Java und/oder C++... Das template-System von C++ ist viel komplexer und 
mächtiger als die Java-Generics, C++ hat Destrukturen & damit RAII, 
Operator-Überladungen, Default-Parameter, Typ-Aliase, Typfunktionen, 
usw...

kalterkaffee schrieb:
> Arduino benutzt zwar C++ um die Bibliotheken zu machen ist aber eher was
> selbstgestricktes.
Nö, die Basis-Sprache für sowohl Biblitoheken als auch Anwendungen ist 
immer noch C++

kalterkaffee schrieb:
> Bei C++ hast Du neben mehrfacher Vererbung auch kein Runtimecontainer,
> d.h. während bei JAVA ein NULLPOINTER abgefangen wird kannst Du mit C++
> den Rechner zerschießen.
Quatsch, da stürzt höchstens das Programm ab. Höchstens bei Bare-Metal 
Programmierung könnte da was "kaputt" gehen.

kalterkaffee schrieb:
> Ich persönlich würde QT und C++ JAVA vorziehen, beides ist Plattform
> unabhängig aber C++ nativ ist deutlich schneller als JAVA.
Das kann man keineswegs so pauschal sagen. Die Laufzeitumgebung von Java 
ermöglicht diverse Optimierungen, von denen C++ nur träumen kann; zB 
dass das Java Programm immer für den CPU des Nutzers optimiert 
(just-in-time kompiliert) wird und diesen somit optimal nutzt, während 
die meisten C++ Programme für den kleinsten Nenner der meistverwendeten 
CPU's optimiert werden (zB typischerweise den uralten 80386) und somit 
die Vorteile moderner CPU's gar nicht nutzen können.

kalterkaffee schrieb:
> Um OO lernen kommst Du bei beiden nicht herum !
Naja, C++ ist eine Multi-Paradigmen-Sprache, die einem OOP nicht 
aufzwingt. Selbst in Java kann man prozedural nicht-OOP coden (alles 
schon gesehen).

Der in der Praxis relevanteste Hauptunterschied von Java und C++ wird 
gerne übersehen, nämlich dass die Speicherlayouts von Funktionen & Daten 
in kompilierten C++ Programmen/Libraries typischerweise fix sind, 
während sie in Java flexibel sind. Dies erzwingt in C++ die 
Rekompilierung sämtlicher Anwendugen wenn bestimmte Änderungen an 
Libraries gemacht werden, während Java-Programme bei den meisten 
Änderungen Binary-Kompatibel bleiben. Dies vereinfacht die Nutzung & 
Deployment von Java-Anwendungen drastisch, und ermöglicht in 
Zusammenhang mit der Einfachheit mächtige Entwicklungstools, die in C++ 
nicht möglich sind. Dies ist für eine konkrete Sprachwahl stark 
ausschlaggebend.

Daniel A. schrieb:
> Auch in C++ können dynamisch Libraries erstellt und dynamisch geladen
> werden, sofern es das OS zulässt oder man es manuell macht.
Korrekt, aber auch diese Libraries haben statische Speicherlayouts. 
Greifst du vom Programm aus auf Daten der Library zu, musst du das 
Programm neu kompilieren wenn sich das Layout in der Library ändert 
(Felder/virtuelle Funktionen vorher hinzufügen zB).

Andreas R. schrieb:
> C++ hat nun all die schönen Datenstrukturen von Java bekommen. Also
> von String bis Vector usw.
Du meinst: Du hast sie nun gefunden. C++ hat die schon lange.

Andreas R. schrieb:
> Aber: die werden ja in den Standardlibs fast
> nirgends verwendet?
Klar werden die verwendet. Meistens implizit über template-Argumente.

Andreas R. schrieb:
> will
> den dann z.B. trimmen, in Tokens zerlegen usw, aber die Funktionen dort
> erwarten ja einen char * , aber keinen String?
Die C++ Standard Library hat keine trim/zerlege Funktion. Vielleicht 
meinst du eine C library, die kann natürlich keine C++ Strings.

Thomas W. schrieb:
> Und weil Java so gut optimiert werden kann, sind alle Java-Anwendungen
> ausnahmeslos schneckenlangsam?
Weil viele Programmierer ausschließlich Java beherrschen und weil viele 
Programmierer schlecht sind, ist ein "großer" Anteil der 
Java-Anwendungen langsam. Man kann in allen Sprachen schlecht und 
gut/effizient programmieren, und Java selbst limitiert da wenig.

Thomas W. schrieb:
> und das ist nur wirklich keine
> Raketentechnik an Software.
Eben doch, Eclipse ist ein hochkomplexes Framework das aus einer Unzahl 
an Komponenten besteht. Wenn da nicht überall hohe Codingstandards 
herrschen, wirds nunmal langsam...

kalterkaffee schrieb:
> aber C++ nativ ist deutlich schneller als JAVA.
Kommt darauf an. Ich hatte mal ein paar Vergleiche gemacht, bei denen 
Java durchgängig schneller war. War damals JDK 1.2 und Visual Studio 6.
Java kann den Heap effizienter managen als C++ (gar nicht). Die Tests 
handelten hauptsächlich um Objekt-Erzeugung und -Destruktion.
Eine Runtime für C++ wie in Java gibt's zudem auch.

Markus schrieb:
> Java kann den Heap effizienter managen als C++ (gar nicht).

auch C(++) kann das

siehe: http://www.microquill.com/smartheap/

Es liegt m.E. immer am Entwickler, der Skalierfähigkeit der Anwendung 
(abhängig von der Datenkonstellation) und der Umgebung, wie schnell eine 
Anwendung läuft, nicht an der Programmiersprache. Wir haben in der Firma 
gut 1,5 Mio. LOC in Java für eine Enterprise Application und keine 
Performance Probleme.

Eclipse für Java mit Maven ist unter Linux mit EXT4 richtig flott, unter 
Windows weniger bei richtig großen Projekten (1 Mio. LOC und mehr, liegt 
am lahmen NTFS). Eclipse für Java kann auch viel mehr als Eclipse für 
C++ oder Visual Studio (Navigieren durch den Code (Call Hierarchie, 
Symbol Search, ...), Plugins für Unused Code (UCDetector), Testabdeckung 
(EclEmma), Maven, undendlich viele 3rd Party Libraries, ...). Und alles 
kostenlos.

Die ganzen Amateurprojekte, um die es hier meist geht, meine hier 
Zuhause auch, sind für Entwicklungsumgebungen doch alles nur Pipifax.

Programmierer schrieb:
> Weil viele Programmierer ausschließlich Java beherrschen und weil viele
> Programmierer schlecht sind, ist ein "großer" Anteil der
> Java-Anwendungen langsam. Man kann in allen Sprachen schlecht und
> gut/effizient programmieren, und Java selbst limitiert da wenig.
Ich habe mal den Test gemacht und bin zu dem Ergebnis gekommen, dass 
einfache, aber rechenintensive Anwendungen, wie Primzahlsuche gleich 
schnell waren. Es heißt auch immer wieder, dass Java inzwischen 
mindestens so schnell wie C++ ist (hier ja auch).
Dann frage ich mich aber, warum Minecraft mit seiner wirklich extrem 
einfachen Graphik meinen Computer so hoch auslastet, während andere 
Spiele mit guter Graphik flüssig laufen. Ist Markus Persson so ein 
schlechter Programmierer?

Programmierer schrieb:
> Das kann man keineswegs so pauschal sagen. Die Laufzeitumgebung von Java
> ermöglicht diverse Optimierungen, von denen C++ nur träumen kann; zB
> dass das Java Programm immer für den CPU des Nutzers optimiert
> (just-in-time kompiliert) wird und diesen somit optimal nutzt, während
> die meisten C++ Programme für den kleinsten Nenner der meistverwendeten
> CPU's optimiert werden (zB typischerweise den uralten 80386) und somit
> die Vorteile moderner CPU's gar nicht nutzen können.

Ja stimmt, aber die meisten Optimierungen werden auf dem Desktop gar 
nicht gemacht, weil es die Latenz/Startgeschwindigkeit drastisch erhöht. 
Deshalb ist Java auf Servern auch um einiges beliebter, da kann man sich 
die Zeit nehmen.

Thomas W. schrieb:
> Theoretisch mag das ja alles der Fall sein, aber praktisch merkt man
> jeder Java-Anwendung sofort an, dass es eben eine Java-Anwendung ist.
> Bestes Beispiel ist Eclipse, und das ist nur wirklich keine
> Raketentechnik an Software.

Mein Eindruck ist das Java massiv mehr Speicher braucht (warum 
eigentlich, alles nur wegen schlechter Programmierer?) und deshalb immer 
langsamer ist. Der Speicher muss schließlich verwaltet werden.

Programmierer schrieb:
> Thomas W. schrieb:
>> Und weil Java so gut optimiert werden kann, sind alle Java-Anwendungen
>> ausnahmeslos schneckenlangsam?
> Weil viele Programmierer ausschließlich Java beherrschen und weil viele
> Programmierer schlecht sind, ist ein "großer" Anteil der
> Java-Anwendungen langsam. Man kann in allen Sprachen schlecht und
> gut/effizient programmieren, und Java selbst limitiert da wenig.

Das Problem ist vor allem, dass Java schon immer damit propagiert hat, 
dass man sich ab sofort um die Speicherverwaltung (dank GCC) nicht mehr 
kümmern muss. Aber das stimmt nicht, du solltest eben nicht überall und 
vor allem in Schleifen mit new um dich werfen. Die Sprache hat das denen 
quasi so angelernt, also ist Java doch selbst daran Schuld?

Heute mal anonym schrieb:
> Ich habe mal den Test gemacht und bin zu dem Ergebnis gekommen, dass
> einfache, aber rechenintensive Anwendungen, wie Primzahlsuche gleich
> schnell waren. Es heißt auch immer wieder, dass Java inzwischen
> mindestens so schnell wie C++ ist (hier ja auch).

Da greift die Java Laufzeitumgebung auch kaum ein und solche Fälle sind 
relativ einfach zu optimieren.

Heute mal anonym schrieb:
> Dann frage ich mich aber, warum Minecraft mit seiner wirklich extrem
> einfachen Graphik meinen Computer so hoch auslastet, während andere
> Spiele mit guter Graphik flüssig laufen. Ist Markus Persson so ein
> schlechter Programmierer?

Zu seiner Verteidigung muss man sagen, dass Minecraft als Hobbyprojekt 
angefangen hat und natürlich der Erfolg nicht abzusehen war. Wenn er das 
gewusst hätte, dann hätte er sicher mehr Arbeit in das Fundament 
gesteckt. Ich denke mal, dass das der Hauptgrund ist.

TriHexagon schrieb:
> Zu seiner Verteidigung muss man sagen
Eher zur Verteidigung von Java. Ich denke, dass die geringe 
Geschwindigkeit an Java liegt.
Ohne das belegen zu können, habe ich das Gefühl, dass Java mit C++ 
mithalten kann, wenn nicht viel auf den Speicher zugegriffen wird. 
Sobald aber der Speicher oft geleert, neu geschrieben und aktualisiert 
werden muss, wie es bei Graphik (und anderen Situationen) der Fall ist, 
bricht Java ein.
Ich halte Java für eine gute Sprache und inzwischen programmiere ich 
viel lieber in Java als in C++, weil vieles einfacher ist, aber wenn es 
auf Effizienz ankommt, würde ich trotzdem auf jeden Fall C++ vorziehen.
Beide Sprachen habe ich übrigens schon professionell für kommerzielle 
Produkte eingesetzt.

@Heute mal anonym, ja da stimme ich dir zu. Ich hab früher mal viel mit 
C# zu tun gehabt, es geht wirklich leichter von der Hand. Die Sprache 
trägt auch kaum Altlasten mit sich und ist recht sauber aufgebaut.

Heute mal anonym schrieb:
> Ohne das belegen zu können, habe ich das Gefühl, dass Java mit C++
> mithalten kann, wenn nicht viel auf den Speicher zugegriffen wird.
> Sobald aber der Speicher oft geleert, neu geschrieben und aktualisiert
> werden muss, wie es bei Graphik (und anderen Situationen) der Fall ist,
> bricht Java ein.

Bei Grafik hat Java eben noch zwei extreme Nachteile.

Erstens kann man in Java keine eigenen Wertetypen deklarieren, d.h. alle 
Typen außer die Standarddatentypen kommen auf dem Heap. Wenn ich mal 
schnell kurzzeitig einen Vektor oder eine Matrix brauche, ist es nicht 
möglich das auf dem viel schnelleren Stack abzulegen, sondern nur auf 
dem Heap, was wiederum einiges an Performanz kosten kann. Bei C++ kein 
Problem.

Zweitens sind Drawcalls bei Java viel teurer, da muss man erst mal 
durchs JNI und Parameter müssen gegebenenfalls umgewandelt werden, keine 
schöne Sache. Besonders wenn man mehrere tausend davon hat.

Hans-Georg L. schrieb:
> Objekterzeugung ist in Java wesendlich teurer wie in C++, von daher
> möchte ich deine Tests anzweifeln.
Hast also selbst noch keinen derartigen Test durchgeführt.

Just in time compiler sind aber nicht sehr verbreitet und die JVM ist 
nunmal ein 8bit Interpreter der die compilierten classes verwaltet.
Per JNI wird auf die JVM oder andere native Programme zugegriffen, dann 
gibt's noch Reflections und sicherlich noch die eine oder andere 
Variante nativen Code einzubinden bzw. auszuführen.
Nur ändert das nichts an der Tatsache das nativ compilierter C++ Code 
schneller ist, auch wenn man QT nimmt was mit den Slots ja auch eine 
"Erweiterung" von C++ beinhaltet.
Meiner Meinung nach gibt sich C++11 mit QT nicht viel mit JAVA, bei 
beiden sollte man setter und getter benutzen und jeweils die Variablen 
private machen.
Es ist halt geschmackssache was man lieber mag, aber Programmiersprache 
ist Programmiersprache, wichtiger ist ein gutes Grunddesign.
Ob ich nun einen KFZ-Steuerrechner in BASIC, C#, JAVA, C++ oder XYZ 
schreibe bleibt sich gleich, nur muß der Rechenweg stimmen.
Ob das Ergebnis nun in 3D ausgegeben wird oder als Text auf der Konsole 
ändert ja nix am Ergebnis.
Aber http://www.klickibunti.org/buntibunti.php ist ja wichtiger ...

kalterkaffee schrieb:
> Just in time compiler sind aber nicht sehr verbreitet

Die HotSpot JVM gibt es schon seit den 90ern und die ist ziemlich 
verbreitet.

Und der Datentyp int hat 32 Bit. Ja der compilierte Java-Code wird auch 
Byte-Code genannt, aber deswegen ein 8-Bit-Interpreter. Klingt nach 
Vorurteilen gepaart mit Ahnungslosigkeit. Nicht selten hier.
Eigentlich mag ich kalten Kaffee, aber ich hoffe der hat bei mit nicht 
so gewirkt.

Das Opcode-Feld im Instruction-Word eines ARM ist 4 bit breit. Ist es 
deshalb eine 4-Bit Maschine?

Hallo Udo,

Udo S. schrieb:
> 1. Wer braucht wann überhaupt die volle Geschwindigkeit des Rechners,
> meist wird doch nur auf Eingaben des benutzers gewartet.

Das ist im Server- und im BigData-Umfeld anders.

> 2. Mit beschissener Programmierung kann man ganz schnell ein Programm um
> den Faktor 100 oder 1000 langsamer machen. Je komplexer die Sprache,
> desto schneller ist man in einem Fallstrick.

Es ist richtig, daß man mit schlechter Programmierung ein Programm um 
viele Faktoren langsamer machen kann. Und nicht nur damit: schlechtes 
Softwaredesign ist ein noch viel, viel schlimmerer Performancekiller.

Falsch ist hingegen, daß das pauschal an der Sprache liegen müsse. Es 
hat nichts mit der Sprache zu tun, wenn Softwaredesigner oder 
Programmierer ihr Handwerk und / oder ihre Werkzeuge nicht beherrschen. 
Es hat auch nichts mit der Sprache zu tun, wenn die 
Entwicklungswerkzeuge langsamen Code erzeugen und / oder die 
Laufzeitumgebung imperformant ist. Das sind nur Eigenheiten der 
jeweiligen Implementierung, nicht der Sprache.

> Fazit: Wer Java pauschal als langsam und blöd verteufelt hat es nie
> ernsthaft benutzt

Richtig. Wir entwickeln (und verkaufen, natürlich) eine Java-Software 
zur Betrugsprävention bei Banktransaktionen aller Art; da sind harte 
Echtzeit mit Latenzen im Bereich von weniger als 50ms, sehr komplexe 
Berechnungen und die Verwaltung großer Datenmengen (Kreditkarten-, 
Terminalhistorien) im Bereich mehrerer hundert Gigabyte gefragt. Das 
geht mit Java ziemlich gut, wenn man weiß, was man tut.

> In unserer Firma spart es uns Faktor 2 der
> Entwicklungs und Deploymantzeit bei ausreichend guter Performance.

Nach den letzten Erhebungen, die ich bei Dr. Dobbs gelesen habe und die 
über etwa 6000 verschiedene Projekte erhoben worden sind, hat Java durch 
die automatische Speicherverwaltung einen Vorteil von rund 15% bei der 
Entwicklungszeit; das entspricht auch meinen eigenen Erfahrungen.

Auf der anderen Seite sorgt ebendiese automatische Speicherverwaltung in 
unserem Anwendungsfall immer wieder für Probleme, weil der GC sich nur 
teilweise konfigurieren und beeinflussen läßt. Das ist nicht schön, aber 
beherrschbar -- und frißt einen Teil der höheren Entwicklerproduktivität 
gegenüber C++ leider wieder auf.

Nach meiner Erfahrung haben übrigens etwa 90% der Softwareentwickler, 
egal in welcher Sprache, nur wenig Erfahrung mit Performancefragen -- 
und zwar vor allem deshalb, weil sie das nie wirklich gebraucht haben. 
Darum halte ich die "Argumente" gegen bestimmte Sprachen, diese seien zu 
langsam oder verbrauchten zuviel Speicher oä., alle für vorgeschobene 
Pseudoargumente, die eine ideologische Präferenz oder schlichte 
Unkenntnis so zu erklären, daß sich die "Begründung" irgendwie 
vernünftig und fundiert anhört. Wenn die Performance immer so wichtig 
wäre, dürfte es gar keine Skriptsprachen geben.

Liebe Grüße,
Karl

> 8-Bit Architektur ist ein definierter begriff. 8-Bit Interpreter und
4-Bit Maschine jedoch nicht, also kann ich die n-bit in einen beliebigen
Zusammenhang setzen, und das Opcode-Feld passt gerade.

Genau was ich mit meinem Post andeuten wollte: "8-Bit Interpreter" ist 
eine völlig nutzlose Information.


Zu BigData: wichtig ist dabei eher die erreichte Speicherbandbreite als 
die Frage, ob ich einen oder fünf Maschinenbefehle brauche. Wenn ich mit 
jeden Zgriff einen Cache-Miss erzeuge, dann macht die CPU nur 
Wartezyklen. Wenn ich durch geeignet Speicherlayout eine Cache-Line 
möglichst ganz ausnutze, dann wird das was. Wenn ich wie bei Java den 
Heap als eine Art Ringpuffer benutze, d.h. Immer am freien Ende Objekte 
anlege und man davon ausgeht, daß gerade erzeugte Objekte mit größerer 
Wahrscheinlichkeit benutzt werden als ältere, dann wird der Hotspot im 
RAM kleiner und es paßt mehr davon in den Cache. Nachteil ist das den 
Datenmüll auch jemand aufräumen muß. Werden Speicherbereiche dagegen 
immer wieder freigegeben, dann fragmentiert der benutzte Speicher und 
ein Teil des Cache-Inhalts hat eigentlich keinen Inhalt. Die Hitrate, 
damit die effektive Speicherbandbreite bricht ein und die CPU kann 
locker Byte-Code interpretierend mithalten.
Wie ich darauf komme? Nun, ich arbeite an Rechnern, in denen 
Terabyteweise RAM steckt. Der Unterschied zwischen richtig und falsch 
kann da locker ein 3-stelliger Faktor sein.

Der Unterschied zwischen Java und C++?

Naja, Java ist eine Insel.

Viele Grüße, Kurt

Golang liegt dazwischen und ist sehr interessant.

Daniel A. schrieb:
> Eine Variable C, die Incrementiert wird. Weiss doch jeder auf java.

Wichtig ist: post-increment. Erst wird C benutzt und dann der Wert um 
eins erhöht.