Plattformunabhängigkeit?

Quote:

Originally Posted by MrSm!th Was genau passiert mit der Garbadge Collection, wenn man nativ kompiliert? Die VM, die jene bereitstellt, fällt dann ja weg. Wird einmal allozierte Speicher dann nicht wieder freigegeben? Immerhin kann der Compiler zur Compile Time ja noch nicht wissen, wann ein Objekt keine Verweise mehr haben wird, also kann er das schlecht da schon einbauen. Und ein explizites delete gibt es nicht (aus etwas anderen Gründen einer meiner größten Kritikpunkte an Java).

meine vermutung wäre dass der speicher (wie es allen anderen prozessen ist) erst nach dem beenden wieder freigegeben wird, was allerdings erstaunlich scheisse wäre :rolleyes:

bin mir aber sicher dass es auch in java delete gibt..

Eine Programmiersprache stellt eine Abstraktion von Programmen dar und ohne eine Notation und Standards kann man sie schlecht als Programmiersprache bezeichnen.
Durch eine Notation wird sie logischerweise plattformunabhängig.
C++ bleibt sowohl unter Linux als auch unter Windows C++, sofern es Compiler gibt, die C++ mit dessen Standards unterstützt.
Nur ist C++' Funktionsbibliothek eingeschränkt, sodass man häufig auf das API des OS zurückgreifen muss. Quellcodes mit OS-abhängigen Funktionen sind immernoch plattformunabhängig und lassen sich mit einem funktionieren Compiler überall kompilieren, nur sind die Kompilate eben nicht mehr plattformunabhängig.

Und genau darum geht es bei Plattformunabhängigkeit. Dass eine Programmiersprache unabhängig ist, ist logisch, nur ist die Frage, ob man das Kompilat auf jedem System einfach so ausführen kann.
Natürlich ist es ein großer Unterschied, dass C++ in Maschinencode kompiliert wird und Java in einen Zwischencode, der dann interpretiert wird, oder in Skriptsprachen direkt der Quelltext interpretiert wird und als Programm dient.
In Hinsicht auf Plattformunabhängigkeit ist diese Eigenschaft jedoch belanglos, da es auf die Ausführbarkeit ankommt.

Und da interpretierte Sprachen komplett vom System abstrahiert werden, lassen sie sich auf jedem System ausführen, das einen entsprechenden Interpreter besitzt.

C++ lässt sich auf anderen Systemen genauso neu kompilieren.
Da C++ aber keine abgeschottete Laufzeitumgebung besitzt wie Skriptsprachen oder Java, stößt man schnell an Grenzen wohingegen Source Codes in Java oder Ruby direkt überall ausgeführt werden können.

Quote:

Wird einmal allozierte Speicher dann nicht wieder freigegeben?

Wie wär's mit einem Referenzzähler?

Kurz und knapp: sowohl Java als auch C++ oder FORTRAN oder auch Basic sind auf ihre weise systemunabhangig nur bei z.b. Java hat man den Vorteil, dass du deine Programme nur geringfügig anpassen müsst bei c++ aber wahrscheinlich Großteile auf das entsprechende os und die apis anpassen müsst.

Aber auch da gibt es viele aushilfen für viele kompilierten Sprache (große sehr umfangreiche libs die für jedes der großen os erstellt werden)

Kurz und knapp: sowohl Java als auch C++ oder FORTRAN oder auch Basic sind auf ihre weise systemunabhangig nur bei z.b. Java hat man den Vorteil, dass du deine Programme nur geringfügig anpassen müsst bei c++ aber wahrscheinlich Großteile auf das entsprechende os und die apis anpassen müsst.

Aber auch da gibt es viele aushilfen für viele kompilierten Sprache (große sehr umfangreiche libs die für jedes der großen os erstellt werden)

Quote:

Wie wär's mit einem Referenzzähler?

Der wird doch in der JVM verwaltet oO
Schließlich ist sie für die Garbage Collection zuständig.

Quote:

bin mir aber sicher dass es auch in java delete gibt..

Da liegst du falsch.

Du ummantelst Zugriffe auf alloziierten Speicher mit Prolog- und Epilog-Code, zählst die Referenzen und gibst bei 0 den Speicher wieder frei (siehe Delphi).

D.h. nativer Code wird dann größer als der VM Code?

Davon ist auszugehen ja ;)

Naja, das doch in jedem Fall :P
Ich kann mir gut vorstellen, dass Java's ByteCode-Instruktionen um einiges komplexer als das x86/x86-x64 Instruction Set sind und man dadurch evtl. weitaus weniger Befehle braucht (die letztendliche Größe der Datei hängt natürlich auch davon ab, wie die Instruktionen im ByteCode kodiert werden, könnte man ja einfach mal testen und vergleichen)

Aber ja, es wird wahrscheinlich viele Overheads geben, dazu kommt bestimmt noch ein großer Startup-Code und verschiedene Prologe und Epiloge für x und y (schätzungsweise alles ein bisschen so wie in Delphi)

Quote:

D.h. nativer Code wird dann größer als der VM Code?

sehr warscheinlich. die Java VM dient ja nicht nur als interpreter, sondern nimmt auch gewissen code ab, der nicht in das endprodukt geschrieben werden muss.

Den referenz zähler gibt es ja z.b. auch bei Objective C, wo jede von NSObject abgeleitete Klasse einen referenzzähler besitzt (allerdings muss der entwickler diesen selbst im Quellcode ansprechen, d.h. sobald der pointer kopiert wird muss eine bestimmte prozedur aufgerufen werden, und wenn der pointer wieder freigegeben wird das entsprachend gegenstück)

BTW Seit wann unterstützt sowas? (Bin mit meinem D7 wohl ein bisschen zurückgeblieben)

Quote:

D.h. nativer Code wird dann größer als der VM Code?

sehr warscheinlich. die Java VM dient ja nicht nur als interpreter, sondern nimmt auch gewissen code ab, der nicht in das endprodukt geschrieben werden muss.

Den referenz zähler gibt es ja z.b. auch bei Objective C, wo jedes von TObject abgeleitete Objekt einen referenzzähler besitzt (allerdings muss der entwickler diesen selbst im Quellcode ansprechen, d.h. sobald der pointer kopiert wird muss eine bestimmte prozedur aufgerufen werden, und wenn der pointer wieder freigegeben wird das entsprachend gegenstück)

BTW Seit wann unterstützt sowas? (Bin mit meinem D7 wohl ein bisschen zurückgeblieben)