Java-Linux

[gms]

Aber VIEL schlimmer noch!!
gms hat behauptet, dass diese 1-Byte Datentypen Restriktionen der JVM seien, die kein C-Compiler umgehen könnte.

(Das heisst auf Deutsch: Jeder C-Compiler auf der JVM KANN NUR 1-Byte-Datentypen umfassen. Das ist blanker Unsinn!!!)

Wie oft soll ich dich noch darauf hinweisen, daß ich so einen Unsinn nie behauptet habe ? Diesen Unsinn behauptest nur du hier.
( Blöder Frage, das ist jetzt natürlich das letzte Mal, Hoffnung hege ich ja keine, daß du das jemals verstehst )

Hier nochmals das Zitat:

selbstverständlich kann auch dieser Compiler nicht an den Limitierungen der JVM vorbeiwurschteln, daher gibt es auch diese sogenannte "Restrictions":

Diese aufgezählten "Restrictions" sind aber, für jeden normalen Menschen auch verständlich, die Restriktionen DIESER Compiler-Implementierung. Diese Restriktionen der Datentypen beziehen sich daher darauf, was DIESER Compiler mittels 'sizeof' Operator zurückliefert und stimmen nicht einmal mit dem überein, wie die Datentypen dann in der JVM TATSÄCHLICH behandelt werden. Daher kannst du aus diesem Zitat, auch nicht wenn du dich noch so sehr verkrampfst, ableiten, daß ich behauptet hätte, die JVM KANN NUR 1-Byte Datentypen umfassen

Nochmals das Zitat von gms

gms@gms2 ~/test2 $ java test2
sizeof char = 1 ( 8 bit )

das ist die Ausgabe, den der von mir gepostete Beispiel-Code, compiliert mit dem besagten Compiler auswirft. Na und ? Du kannst es gerne selber überprüfen, statt hier herumzutrollen

[gms]

@bmario
Meine Erklärung warum dieser Compiler den sizeof Operator so derartig verhunzt:
Wenn man die Pointer Arithmetik von C auf Java umlegt, dann bleibt einem nicht viel mehr als auf Arrays von einem gewissen Datentyp auszuweichen und über den Index diese Pointer Arithmetik nachzubilden. Jetzt könnte man daher für einen Pointer von Typ 'int' z.B ein int-Array nehmen, dann hat man aber noch das Problem, daß unter C JEDES Byte eines Objekts über Pointer vom Typ 'char' addressierbar sein muß. Das kann ich natürlich nicht mehr nachbilden, wenn ich in der JVM von einem int-Array ausgehe. Trotzdem brauche ich in der JVM mindestens ein int-Array, damit ich auch die Integer-Werte dort ablegen kann.
Es bleibt also nur die Möglichkeit ( mir fällt jedenfalls keine bessere ein ), unter C diese Datentypen mit gleicher Länge zu definieren und diese still und heimlich in der JVM auf den tatsächlichen Typ zu mappen. Das entspricht zwar keinem C-Standard mehr, man kann aber wahrscheinlich bei einigen Projekten sehr gut damit leben !

Gruß
gms

[schorsch_76]

Hallo gms,

hier muss ich dir voll und ganz zustimmen. Es ist ein Problem der Compiler Implementierung. Wenn das Int Array bsp. gecastet wird, und ich die Bytes einzeln bearbeiten will, verhalten sich bsp gcc und der C zu JVM Compiler unterschiedlich. Meiner Meinung nach wäre dies für das "Java-Linux" ein verherendes Problem.

Gruß

schorsch

[gms]

Es ist ein Problem der Compiler Implementierung. Wenn das Int Array bsp. gecastet wird, und ich die Bytes einzeln bearbeiten will, verhalten sich bsp gcc und der C zu JVM Compiler unterschiedlich.

ja, aber, nachdem die Java VM keine Pointer Datentypen untestützt ( warum sollte sie auch ), halte ich die Lösung dieses Compilers noch für den besten Kompromiss.
Alternativ müßte das Array ( zumindest partiell ) umkopiert und alle vorhandenen Referenzen auf dieses Array aktualisiert werden. Wenn das Array nur partiell kopiert wird, müßten die vorhandenen Teile, dann auch noch zusätzlich synchronisiert werden...
also diese Lösung gefällt mir noch viel weniger

Mal abgesehen von dem Compiler-Bug mit dem Type-Casts, hier wäre eventuell eine Art "libcforj.jar" hilfreich, ist der Compiler aber sicherlich in so manchen Projekten sehr gut einsetzbar.

eine kleine Anmerkung noch zu:

Man" geht oft, seht oft einfach davon aus, dass ein char = 1 Byte ist. Ein int = 4 Bytes,

Byte ist unter C als kleinste addressierbare Einheit definiert ( bitfield bitte ausklammern ), daher ist 'char' immer 1 Byte ( im Sinne von C ) lang ( andernfalls wäre in einem 'char' Objekt nicht jedes Byte addressierbar )
Die Anzahl der Bits in diesem Byte sind daher durch CHAR_BIT (>=8) bestimmt und jedes Objekt hat eine Länge sizeof(T) * CHAR_BIT

edit: also ein 'char' könnte unter C z.B auch 16 bit lang sein, wäre aber trotzdem nur 1 C-Byte lang.

Gruß
gms

[schorsch_76]

Hallo gms,

der Standard sagt ja nur welche min/max Werte der Datentyp aufnehmen können muss (zumindest hab ich nur dies gefunden). Zur Grösse (im Speicher) der Datentypen hab ich im Standard nichts gefunden (muss aber nicht heissen dass es dort nicht steht)

Gruß

schorsch

[gms]

der Standard sagt ja nur welche min/max Werte der Datentyp aufnehmen können muss (zumindest hab ich nur dies gefunden).

wahrscheinlich meinst du das gleiche:
der Standard bringt Vorschläge für diese MIN/MAX Werte, die von der Compiler-Implementierung jedoch in absoluten Werten überschritten werden kann.
z.B
SCHAR_MIN -127
SCHAR_MAX 127
Hier kann ein Compiler-Hersteller z.B auch für SCHAR_MIN den 'üblichen' Wert von -128 einsetzen, ein anderer könnte theoretisch aber auch z.B den Bereich von -32768 bis 32767 wählen

Zur Grösse (im Speicher) der Datentypen hab ich im Standard nichts gefunden (muss aber nicht heissen dass es dort nicht steht)

der Standard definiert hierfür das 'Byte' und den sizeof Operator, der die Größe eines Objekts in Bytes zurückliefert. Somit hat man einmal die Größe eines Objekts in C-Bytes.
Zusätzlich definiert der Standard CHAR_BIT als die Länge vom kleinsten Objekt ( also die Länge eines Bytes ) in Bits. Somit läßt sich auch die Größe ( im Speicher ) eines Objekts ( in Bits ) bestimmen ( Alle Integer-Typen außer 'char' dürfen aber auch Padding-Space beinhalten, dieser wäre hier mit eingerechnet )

( edit: CHAR_BIT kann auch vom Compiler-Hersteller auf Werte >= 8 gesetzt werden )
( edit2: natürlich dürfen auch andere Datentypen einen Padding-Space beinhalten, wichtig ist hier nur, daß dies bei 'char' nicht erlaubt ist und somit der volle CHAR_BIT Bereich auch als Wertebereich von 'char' angenommen werden kann )

Gruß
gms