Hallo,
ich beschäftige mich schon sein einiger Zeit mit der Sprache
C++(Arduino).
Nun versuche ich JAVA zu lernen.
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)}
Diese drei Schritte mache ich immer.
Wie ist es nun bei JAVA.
Da sieht es so aus.(ein Beispiel von Youtube)
public class
public static void main(String[]args){}
hat jedes Programm das selbe Schema?
Vielleicht kann mit jemand Tipps geben.
Oder vielleicht weiß jemand ein hilfreichen link wo alles genau erklärt
ist.
Danke
:
Verschoben durch Admin
Markus94 schrieb: > Da sieht es so aus.(ein Beispiel von Youtube) Youtube ist keine gute Idee. Es gibt im Web jede Menge Tutorien, die dich mit dem gedruckten Wort durch die Anfänge führen. > hat jedes Programm das selbe Schema? Ja. In Java ist alles und jedes in einer Klasse verpackt. Auch main(). > Oder vielleicht weiß jemand ein hilfreichen link wo alles genau erklärt > ist. Google ist dein Freund.
:
Bearbeitet durch User
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.
Der Andere schrieb: > "java ist auch eine Insel" > Ist ein Onlinebuch, Das Buch gibt es außerdem auf totem Baum.
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 :-)
Ich hätte da mal kurz eine Frage. Erzeugt die Laufzeitumgebung von Java dann kein Objekt der Klasse in welcher die public static void main(String[]args) definiert ist ? Auf Mitglieder der Klasse die nicht static sind hätte die main ja eh keinen Zugriff ? Gruß Dennis
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.
Dennis H. schrieb: > Erzeugt die Laufzeitumgebung von Java dann kein Objekt der Klasse in > welcher die public static void main(String[]args) definiert ist ? Nicht automatisch. Aber oft wird innerhalb der main-Funktion ein Objekt der umgebenden Klasse erzeugt und von diesem dann eine oder mehrere Member-Fuktionen aufgerufen, die dann in einem OO-Kontext die Hauptarbeit machen.
Yalu X. schrieb: > Dennis H. schrieb: >> Erzeugt die Laufzeitumgebung von Java dann kein Objekt der Klasse in >> welcher die public static void main(String[]args) definiert ist ? > > Nicht automatisch. Aber oft wird innerhalb der main-Funktion ein Objekt > der umgebenden Klasse erzeugt und von diesem dann eine oder mehrere > Member-Fuktionen aufgerufen, die dann in einem OO-Kontext die > Hauptarbeit machen. Danke. Interessante Idee.
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.
Programmierer schrieb: > 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, Auch in C++ können dynamisch Libraries erstellt und dynamisch geladen werden, sofern es das OS zulässt oder man es manuell macht. Statische Libraries müssen ja nicht verwendet werden. Dennoch können die zur Runtime verfügbaren informationen bei Java (Classen,member,dessen namen und typinformationen), welche mit Java Reflect ausgelesen werden können, echte vorteile bieten. Für mich ist der Hauptnachteil von Java die Notwendigkeit der JVM.
Was mir jetzt nach längerem Java-Coden und C++ - Abstinenz aufgefallen ist: C++ hat nun all die schönen Datenstrukturen von Java bekommen. Also von String bis Vector usw. Aber: die werden ja in den Standardlibs fast nirgends verwendet? Ich mach also ne Usereingabe in einen String, will den dann z.B. trimmen, in Tokens zerlegen usw, aber die Funktionen dort erwarten ja einen char * , aber keinen String? Da muss die Standardlib nach meiner Meinung nochmal ziemlich überarbeitet werden, um das ein wenig runder zu bekommen.
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. Und weil Java so gut optimiert werden kann, sind alle Java-Anwendungen ausnahmeslos schneckenlangsam? 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.
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...
Thomas W. schrieb: > Programmierer schrieb: > Bestes Beispiel ist Eclipse, und das ist nur wirklich keine > Raketentechnik an Software. In welcher Sprache ist Visual Studio geschrieben? Es stimmt schon, dass Java im Allgemeinen eine Bremse ist, ein gutes Beispiel dafür ist Maple, als unter Linux auf eine Java-Gui gewechselt wurde....
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.
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. Und C++ ist so, dass du es entweder kannst, oder dir fliegt dein Projekt frühzeitig um die Ohren. In Java oder beispielsweise .Net bekommt jeder (wahrscheinlich auch ich) noch etwas hingestümpert was nicht sofort abstürzt. Beruflich habe ich mit einer Software von Siemens (TIA-Portal) zu tun. Angeblich ist dies eines der größten .Net Projekte (in C# geschrieben). Und es ist wirklich unglaublich langsam, ungefähr vergleichbar mit einer Java-Anwendung. Vielleicht zieht die vermeintliche "Leichtigkeit" einer Sprache viele schlechte Programmierer an. Ein so großes aktuelles Softwareprojekt in C++ erstellen zu wollen, würde alleine anhand des Personalmangels (fähige Programmierer die C++ beherrschen) scheitern.
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.
Andreas R. schrieb: > Was mir jetzt nach längerem Java-Coden und C++ - Abstinenz aufgefallen > ist: C++ hat nun all die schönen Datenstrukturen von Java bekommen. Also > von String bis Vector usw. Da muß deine Abstinenz aber sehr lang gewesen sein, denn C++ wurde 1998 inklusive dieser Datentypen von der ISO genormt. Die Typen gab's aber schon vorher, denn sie waren die Basis für den Standardbibliotheks-Teil der Norm. Laut Wikipedia gibt es Java seit 1995, also würde es mich nicht wundern, wenn manche der Klassen in C++ älter sind, als die Sprache Java. Programmierer schrieb: > 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). Da gibt es auch Möglichkeiten, Binärkompatibilität zu gewährleisten. Große in C++ geschriebene Frameworks wie z.B. KDE tun das erfolgreich.
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?
Markus schrieb: > 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. Objekterzeugung ist in Java wesendlich teurer wie in C++, von daher möchte ich deine Tests anzweifeln. Das liegt daran das die Vm erst einmal den Classloader anwerfen muss und das Java Threads vor dem Programmierer verbirgt aber dadurch jeden Furz im Hintergrund synchronisiert ob notwendig oder nicht. Ich hatte schon Anwendungen, da musste ich mir Objekt-Pools bauen und Objekte wiederverwenden um ein einigermassen reaktionsfähiges Programm zu haben. Der new operator von C++ erzeugt mit malloc(sizeof(class)) das Objekt und ruft dann den Konstruktor auf aber den Konstruktor muss Java ja auch aufrufen.
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.
TriHexagon schrieb: > 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. Mich stört da noch was anderes dran: Objekte bestehen nicht nur aus Speicher. Es gibt auch noch andere Ressourcen. Die Automatisierung des Speicherhandlings über einen GC geht aber einher damit, daß man sich um alle anderen Ressourcen ab sofort von Hand kümmern muss. C++ bietet keinen grusätzlich aktiven Automatismus, aber die Möglichkeit, es zu automatisieren, und das eben für alle Ressourcen und nicht nur den Speicher.
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.
Bastler schrieb: > Ja der compilierte Java-Code wird auch > Byte-Code genannt, aber deswegen ein 8-Bit-Interpreter. Klingt nach > Vorurteilen gepaart mit Ahnungslosigkeit. Die Opcodes der Instructionen sind 8 bit lang, wenn ich mich richtig erinnere. Ich wollte mal eine JVM in JS schreiben, Ist dann ein disassembler geworden, weil zuwenig zeit.
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.
Ich hatte vor vielen Jahren mal Tests gemacht. Es ging um unscharfe Suche (Edit Distance). Im ersten Versuch die Überraschung, java war etws schneller als C. Das konnte nicht sein, also etwas mehr gesucht und gefunden, dass bei C noch Debug Code erzeugt wurde, In Release und mit Optimierungen auf Gschwindigkeit war dann C knapp doppelt so schnell wie Java. Ist schon lange her war ein älterer MSC Compiler und Java 1.3 Nur: 1. Wer braucht wann überhaupt die volle Geschwindigkeit des Rechners, meist wird doch nur auf Eingaben des benutzers gewartet. 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. Mein Rekord einer Programmbeschleunigung durch Optimierung war der Faktor 10000. Da hatte ein Super-Programmierer eine eigene Speicherverwaltung mit shared Mem gemacht und ist beim Freigeben jedes einzelnen Blocks linear durch eine verkettete Liste. 3. Im heutigen Zeitalter sind die meisten Anwendungen Client Server Anwendungen mit Web Oberfläche. Fat Clients mit dicker grafischer Oberfläche sind eine aussterbende Spezies, eigentlich nur noch im Spiele und Hobby Bereich. Und im Serverbreich wird recht oft java benutzt. 4. Das Deployment mit Java und auch Datenbankanbindungen ist viel einfacher, vor allem wenn unterschiedliche Betriebssysteme und unterschiedliche Datenbanken zusammenkommen. Wir unterstützen hier Unixe, Linux und Windows, mit Oracle DB2 und SQL Server als Datenbank, und das mit EINER! Auslieferung. Einzig Batche und Scripte gibts eben doppelt. Macht das mal mit C(++) Haben wir auch, das sogar für ein halbes Dutzend Host Systeme Vax VMS, IBM MVS sowie diverse Cicse und sogar Siemens Host und AS400 früher. Dazu etwa 10-15 unterschiedliche Datenbanksysteme das war/ist eine einzige Qual. man hatte praktisch für jeden Kunden eine eigene Compilierung. Fazit: Wer Java pauschal als langsam und blöd verteufelt hat es nie ernsthaft benutzt und kann nicht über seinen kleinen Entwicklertellerrand schauen. In unserer Firma spart es uns Faktor 2 der Entwicklungs und Deploymantzeit bei ausreichend guter Performance. Für Spiele und extrem zeitkritische Dinge würde ich auch heute C(++) benutzen, also immer das passende Tool für das Projekt.
:
Bearbeitet durch User
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.