bei C/C++ bleiben oder JAVA lernen?

[xare]

Original geschrieben von anda_skoa

Man bräuchte einen JIT, der den native Code irgendwo cached.
So wie es die VM von C# macht.

Da gibts doch schon verschiedenes, oder?

Original geschrieben von SeeksTheMoon

"besser durchdacht und noch kein Gegenteil gefunden": Das ist ein indirekter Beweis und somit mathematisch gültig

Nope, ein indirekter Beweis ist das nicht...

MfG Xare

[anda_skoa]

Original geschrieben von SeeksTheMoon
Gut, mein ehemaliger C++ Lehrer (ein C++ Gott übrigens) behauptet das übrigens auch. Da sind wir schon zwei...

Hmm, ich hab leider keine Spezifikation der ersten Stunde, jetzt sind Exceptions definitiv der Sprache.

Nachtrag zum "besser durchdacht und noch kein Gegenteil gefunden": Das ist ein indirekter Beweis und somit mathematisch gültig
Is mir nur leider zu spät eingefallen... *g*

Besser durchdacht und noch kein Gegenteil gefunden?
Auf was bezieht sich das?

Außerdem ist das kein indirekter Beweise
Du müßtest beweisen, dass es kein Gegenteil gibt.
Nur bisher keines gefunden reicht da nicht.

Templates kommen in Java 1.5

Feine Sache, dann wird mand as dauernde herumgecaste endlich los

Ciao,
_

[anda_skoa]

Original geschrieben von xare
Da gibts doch schon verschiedenes, oder?

Hmm, bin da nicht so auf dem Laufenden.
Bisher haben die Java JITs immer nur während eines Lebenszyklusses gearbeitet, also nur solange die JVM läuft.
Auf einem Server ist das auch völlig ausreichend, aber Desktopanwendungen werden öfter gestartet und beendet und da ist ein native-cache ganz fein

Ciao,
_

[Lin728]

Nun, ich finde Java ist extrem gut durchdacht, schade dass es im Applikationsmarkt nicht fußen kann/will. Solange Sun keine Java-Compiler veröffentlich, bleibt Java für die meisten eben nur ne aufgeblasene Scriptsprache ;-(

Mfg

[peschmae]

mein senf dazu:

Java ist relativ jung und deswegen von vorn herein besser durchdacht und nicht nachträglich erweitert worden (z.B. Exceptionhandling in C++)

quark. Java ist auch schon fünf seit der Erstveröffentlichung. und an einer Menge Stellen musste sehr stark nachgebessert werden (und auch nachträglich erweitert) (z.B. AWT (das eventmanagement), Swing dazu, das Ersetzen von Vektor durch ArrayList, ...)

Was aber insgesamt nicht gegen java spricht

MfG Peschmä

[anda_skoa]

Original geschrieben von ceisserer
Das ist ja kindisch!

Aber gerade wiels so kindisch ist, mach ich mit ;-)

Wir sind zwar knapp unter einem Flamewar, aber es ist noch eine Diskussion.
würde ich sagen

Nun, ich finde Java ist extrem gut durchdacht, schade dass es im Applikationsmarkt nicht fußen kann/will.

Ich finde Java auch gut, ich hab nur was dagegen, wenn behauptet wird C++ sei schlecht.

Solange Sun keine Java-Compiler veröffentlich, bleibt Java für die meisten eben nur ne aufgeblasene Scriptsprache ;-(

Ich weiß nicht, welche Sachen du runtergeladen hast, aber bisher enthielten alle JDKs von Sun einen Compiler.
Die Pakete ohne Compiler nennt man JRE.

Natürlich kann man sagen, dass mit den JIT das nach einiger Zeit alles besser wird, aber wer bitte führt den Code immer zweimal aus, um schell zu arbeiten.

Darum finde ich die Idee gut, dass man das Ergebniss der JIT Compilierung in einem speziellen Cache speichert.
So wie es auch der JIT von .NET macht.
Wundert mich, dass es da noch keinen Java JIT gibt, der das macht.


Ciao,
_

[peschmae]

was fehlt ist ein nativer Compiler à la Jet oder so

die von javac kompilierten Dinger sind ja wohl dem Sourcecode sehr ähnlich, ist es doch mit den Decompilern sehr gut möglich das Zeugs wiederherzustellen (sogar die Variablen/Methodennamen). Also liegt die Annahme nahe, das sei gar nicht mehr als eine Skriptsprache...

MfG Peschmä

[anda_skoa]

Original geschrieben von peschmae
was fehlt ist ein nativer Compiler à la Jet oder so

Aso, daß muß man schon dazu sagen.

Es gibt von Sun eine Prozessor, der eine Java Maschine implementiert.
Da ist der normale Bytecode native

Es widerspricht der Phiosophie, einen Native Compiler zu machen.
Das würde Leute nur dazu verleiten, Plattformabhängige Binarys zu verteilen.

SUN wird also keinen machen, zumindest nicht als Teil des JDK.

Wie man sieht gibt es aber entsprechende Compiler von Drittherstellern (Compilerspezialisten).

Am besten finde ich aber immer noch einen Caching-JIT.
Das ist "best of both worlds".

Ciao,
_

[peschmae]

Es gibt von Sun eine Prozessor, der eine Java Maschine implementiert.

wartauflink

MfG Peschmä

[Lin728]

Hi,

Ein weiterer großer Hemmschuh ist sicher die "es ist nicht kompiliert, also ist es langsam" Mentalität. Ich habe ein paar Benchmarks mit dem JDK1.4, dem GCJ, Kaffe und JET gemacht. Generell kna man wirklich sagen, dass interpretiertter Code langsam ist. Natrülich, es ist eher ein einfacher Benchmark, der nicht viel über de Gesamtperformnce aussagt, aber naja, trotzdem:
Sun-Java1.4 ohne Jit: 1700msec
Kaffe: 1400 msec
GCJ-3.0.4: 600msec
Sun-Java1.4 mit JIT: 179
Jet-native kompiliert: 10msec.
Bei weiteren läufen kommt se Sun Java.14 mit Jit auf 14msec, als ziemlich naje an JET. Alle anderen Werte bleiben fast gleich. Der GCJ ist höchstwahrscheinlich schon viel schneller geworden, die getestete Version hatte schon ein paar Monate am Buckel...

Man sieht also deutlich, dass einfach nur interpretierter Code mit schlechetm JIT wie z.B. unter Kaffe langsam ist. Auch sieht man, dass sich SUN extreme Mühe gegeben hat, deine Runtime performant zu machen!

Mfg

[peschmae]

Eben, die java - probleme sind imho:

- lange startzeit
- vielzuviel speicherverbrauch
- "" hd - verbrauch
- extrem träge menüs (wenn ein button zwei sekunden zum reagieren braucht ist mir das scheissegal, aber ein menü muss einfach sofort da sein)

MfG Peschmä

[Lin728]

Jo, und da Hilft GCJ mit SWT!

Unter Windows kann man eh mit der normalen JV arbeiten, und für Linux gibts ein Executable, das einer QT-Application um nichts nachsteht!!!

Mfg

[Woolf]

WOW

Wurden hier schon die JAR files errwähnt???? die haben mich begeistert

Das ist wichtig, ein "Applikations Pack"-Tool
Sowas wie ein Zip-Tool

Du kannst die klassen und alles was du für dein prog benötigst mit
>jar cf [foo.jar] [file1/dir1] [file2/dir2]....
"packen"

applets werden dann ganz normal mit
code="foo.class"
angegeben, da isch foo.class im JAR befindet, einfach
archive="xyz.jar"
dazufügen

Soll es ein selbstständiges prog sein, muss einfach eine Main-Klasse rein, ich nehm an, dass das einfach nur "main.class" heißt

http://java.sun.com/docs/books/tutor...ics/index.html


@Seeks: Das ist auch für kleine Demos von Schattenwelten gut, enginge-demos, als applet

[SeeksTheMoon]

Original geschrieben von peschmae
Eben, die java - probleme sind imho:

- lange startzeit
- vielzuviel speicherverbrauch
- "" hd - verbrauch
- extrem träge menüs (wenn ein button zwei sekunden zum reagieren braucht ist mir das scheissegal, aber ein menü muss einfach sofort da sein)

MfG Peschmä

Eine lange Startzeit hat man bei C++ Programmen auch. Bei kleinen Programmen hat C++ aber die Nase vorn, das stimmt.
HD-Verbrauch ist ja wohl MEGAWINZIG. Wenn ein Java-Programm 1MB groß ist, dann steckt da schon einiges hinter. Dafür sind die Bibliotheken zwar groß aber ich kann mir nicht vorstellen, dass das bei C++ anders ist. QT ist ja auch fet (hat da jemand ne Größe in MB?)

@Woolf: ich kenne jar-Files und mache da auch ständig Gebrauch von. Allerdings muss da eine Datei MANIFEST/MANIFEST.MF rein, in der steht, welche Klasse die Main-Methode enthält, dann erst klappts. Ansonsten ist es nur ein Archiv.

[peschmae]

ok, qt ist genauso fett, aber bei Java kommen einfach noch über 50 dazu, aber das ist ein allgemeines Problem (noch gleich >50 für Gtk/Gnome, dann noch Mozilla, ...)

Eine lange Startzeit hat man bei C++ Programmen auch.

Nicht immer! Fltk - Applikationen sind ganz schön schnell. (Fünf Punkte für die, die gewusst haben, dass ich jetzt das bringe )


MfG Peschmä