Ein "long" als String ?

Mathuas

@hustbaer sagte in Ein "long" als String ?:

Auf Linux x86 ist sizeof(long) == sizeof(void*) .
Vom Compiler unabhängig, da Teil der ABI.

So wie es scheint, hat C das gleiche Problem wie Pascal, die Integer sind nicht einheitlich.
Wie es bei Java, Python und co. weis ich nicht.

SeppJ

Es ist schon einheitlich, aber in einem anderen Sinne als eine feste Bitbreite: Als der passendste Typ für die Maschine. Das ist kein Nachteil, sondern ein Vorteil auf einem anderen Gebiet als du dir wünscht. Wenn du feste Bitbreiten willst, musst du eben einen der dafür vorgesehenen Typdefs benutzen. Die halt nicht unbedingt existieren, sondern nur, wenn es die auf der Maschine tatsächlich gibt. Womit man auch einen Teil des Vorteils erkennt: Ein typisches C-Programm, das nicht absichtlich die Typen mit fester Breite benutzt, läuft ohne Änderung auf Systemen mit 24-Bit Bytes. Ja, das gibt es. Ist halt relevant für Sprachen, die auch zur Programmierung von Supercomputern oder Microcontrollern gedacht ist.

PS: Weil mich dafür Beispiele interessierten (sind aber zu viele für eine Liste), hier ein besonders interessanter Fall: Die DEC-10 hatte sogar eine Variable Bytebreite von 1-36. Der GCC hat angeblich Unterstützung für diese Maschine. Aber meine Energie reicht gerade nicht für eine Recherche, was dort als CHAR_BITS oder sizeof(int) definiert ist (Der Link zum ABI ist leider tot).

wob

@Mathuas sagte in Ein "long" als String ?:

Wie es bei Java, Python und co. weis ich nicht.

Bei Python hat int keine Beschränkung (ist also ein bigint).

$ echo 'print(f"{2 ** 100 = }")' | python
2 ** 100 = 1267650600228229401496703205376

Aber wieder natürlich mit interessanten Features wie dass kleine gleiche Zahlen auf dasselbe Objekt zeigen können, große gleiche aber nicht.

>>> j1=10234
>>> j2=10234
>>> j1 is j2
False
>>> i1=5
>>> i2=5
>>> i1 is i2
True

@SeppJ sagte in Ein "long" als String ?:

Es ist schon einheitlich, aber in einem anderen Sinne als eine feste Bitbreite: Als der passendste Typ für die Maschine.

Für Java stimmt dies nicht. Dort umfasst ein

int immer 4 Byte,
long immer 8 Byte,
char immer 2 Byte, (vorzeichenlos)
short immer 2 Byte,
byte immer 1 Byte,
float immer 4 Byte,
und double immer 8 Byte.

Und wie das intern technisch realisiert worden ist, das ist ein Implementierungsdetail der JVM und für den normalen Programmierer im Normalfall völlig irrelevant. Dieser muss nur den gültigen Wertebereich kennen.

Java ist (sehr) streng typisiert.

Oder ... um ganz genau zu sein: statisch, explizit und implizit, stark typisiert; siehe auch hier: https://de.wikipedia.org/wiki/Typisierung_(Informatik)#Beispiele

Mathuas

@Fragender sagte in Ein "long" als String ?:

@SeppJ sagte in Ein "long" als String ?:

Es ist schon einheitlich, aber in einem anderen Sinne als eine feste Bitbreite: Als der passendste Typ für die Maschine.

Für Java stimmt dies nicht. Dort umfasst ein

int immer 4 Byte,

long immer 8 Byte,

char immer 2 Byte, (vorzeichenlos)

short immer 2 Byte,

byte immer 1 Byte,

float immer 4 Byte,

und double immer 8 Byte.

Und wie das intern technisch realisiert worden ist, das ist ein Implementierungsdetail der JVM und für den normalen Programmierer im Normalfall völlig irrelevant. Dieser muss nur den gültigen Wertebereich kennen.

Java ist (sehr) streng typisiert.

Ausser man verwendet einen Vertexpuffer von OpenGL, dann ist die Datenbreite auf einmal sehr wichtig.

@Mathuas sagte in Ein "long" als String ?:

Ausser man verwendet einen Vertexpuffer von OpenGL, dann ist die Datenbreite auf einmal sehr wichtig.

Nein, ist es nicht. OpenGL gehört nicht zu Java.

*john 0

@hustbaer sagte in Ein "long" als String ?:

Auf Linux x86 ist sizeof(long) == sizeof(void*) .
Vom Compiler unabhängig, da Teil der ABI.

Das ist nicht nur auf Linux x86 der Fall, sondern auf jedem OS, dass sich an die Single UNIX Specification hält. Diese definiert nämlich für den 32Bit Modus ILP32 und für den 64Bit Modus LP64. Es gab zwar Abweichungen von der SUS (klassisches UNICOS auf Cray Hardware nutzte SILP64), aber diese sind mittlerweile nur noch als historisch zu bezeichnen, da diese OS keinerlei Rolle mehr spielen.

Mathuas

@Fragender sagte in Ein "long" als String ?:

@Mathuas sagte in Ein "long" als String ?:

Ausser man verwendet einen Vertexpuffer von OpenGL, dann ist die Datenbreite auf einmal sehr wichtig.

Nein, ist es nicht. OpenGL gehört nicht zu Java.
Es ist nicht direkt in Java, aber man kann es einbinden, so wie es bei fast jeder Sprache möglich ist.

Bei Android ist man fast auf das Gespann Java und OpenGL/SE angewiesen.

Das ist aber etwas anderes. Wenn man OpenGL verwenden möchte, nimmt man in 99,99 % der Fälle C++...

Du würdest doch auch nicht versuchen wollen, in JavaScript Assembler zu programmieren...

Mathuas

@Fragender sagte in Ein "long" als String ?:

Das ist aber etwas anderes. Wenn man OpenGL verwenden möchte, nimmt man in 99,99 % der Fälle C++...

Du würdest doch auch nicht versuchen wollen, in JavaScript Assembler zu programmieren...

Das stimmt schon, auf dem PC würde ich auch kein Java für OpenGL nehmen, sondern Pascal, oder wie du sagst C/C++.
Aber bei Android ist dies ein Sonderfall.
Assembler und OpenGL kann man schlecht vergleichen. Assembler ist Maschienensprache, Und OpenGL eine Schnittstelle zu Hardware.
Wen bei OpenGL mal die Daten im VRAM sind, läuft eine Animation auch mit Python angenehm schnell. Die Hardware Beschleunigung ist immer gleich schnell. Aussgenommen WebGL, da läuft nur ein Warper.

hustbaer

@Mathuas
...?