TStringList.IndexOf ein 32Bit Integer ?

[Mathias]

Code: Alles auswählen

Wir sprechen von eine Stringlist. Was willst du denn in 10-20 Jahren in der Stringlist speichern?

Es betrifft auch die gewöhnliche TList.
Ich und du werden dies sicher nie nutzen, aber man weis nie was die Zukunft bringt.

[theo]

Ich und du werden dies sicher nie nutzen, aber man weis nie was die Zukunft bringt.

Man muss es jetzt auch noch nicht wissen
Das ist ja keine Grundsatzentscheidung oder Weichenstellung für die Zukunft.
Sollte das jemals notwendig oder sinnvoll werden, dann kann man das leicht ändern ohne grosse Rückwärtskompatibilitätsprobleme.
Ausserdem glaube ich eher nicht, dass in 10 Jahren ein normales Gerät 100GB RAM hat.

[af0815]

Ausserdem glaube ich eher nicht, dass in 10 Jahren ein normales Gerät 100GB RAM hat.

Na ja, ich bin schon bei 32 GB

Wie beim Auto, je mehr Hubraum umso besser

[theo]

Na ja, ich bin schon bei 32 GB

Das wird auch in 10 Jahren noch reichen.
Und mein 1GB Raspi wird auch noch laufen.

Wie beim Auto, je mehr Hubraum umso besser

Das dürfte in 10 Jahren schwieriger werden.
Hubraum will die EU ja dann abschaffen.

[af0815]

OT: Fortsetzung siehe viewtopic.php?f=13&t=14809

[PascalDragon]

Ich habe gedacht, der Typ Integer passt sich dem Betriebssystem automatsich an
Mindestens jedoch 16 Bit so habe ich das mal erlernt....

Nein. Der Typ Integer war 16-Bit in Turbo Pascal und wurde 32-Bit in Delphi (> 2). In FPC ist der Typ Integer standardmäßig 16-Bit und wird zu 32-Bit in den Modi Delphi und ObjFPC bzw. wenn der Modeswitch ObjPas aktiviert wird (was die beiden Modes machen) und dadurch die Unit ObjPas eingebunden wird, welche Integer = LongInt als Typdeklaration enthält.

Bei 16 Bit und 32 Bit Sytemem geht das ja auch,
aber bei 64 Bit Systemen anscheinend nicht mehr, hab ich grad festgestellt
SizeOf(Integer) ist 4 auf einem 64 Bit System,
das war mir jetzt auch neu.

Wenn der erste 64-bit FPC Compiler eingeführt wurde, wurde beschlossen dies möglichst kompatibel zum 32-Bit Code zu machen, weshalb Integer bei 32-bit belassen wurde. Delphi hatte später die gleiche Entscheidung getroffen, wobei die Entwickler sich dabei wohl eher an Windows orientiert hatten, da dieses das sogenannte LLP64 Modell verwendet, statt dem LP64 Modell, welches die ganzen Unix Systeme nutzen. Ersteres bedeutet, dass long long 64-Bit ist, aber long 32-Bit, während bei letzterem bereits long 64-bit ist. Dies ist auch der Grund, warum in Delphi für macOS der Typ Integer 64-bit ist. FPC folgt diesem Schema jedoch nicht.

[Warf]

ich nehme mal meinen ursprünglichen Post hier weg um keine unnötigen Diskussionen aufkommen zu lassen....
Mich wundert es nur wer den merkwürdigen Typen Integer erfunden hat....

auf einem 8 Bit System ist eine Integer 16 Bit
auf einem 16 Bit System ist ein Integer 16 Bit
auf einem 32 Bit System ist ein Integer 32 Bit
auf einem 64 Bit System ist er auch 32 Bit

Den Zusammenhang muss man erstmal verstehen.....

Verschiedene BIT größen für Integer kommt soweit ich weis aus der C welt, da die Borland beim aufkommen von 32 bit architekturen den selben weg gegangen ist wie C. Und so bescheuert das vielleicht auch klingen mag, hat es einen guten grund warum der C standard diesen weg gegangen ist (ob der Grund gut genug war das Borland ihn abgekupfert hat, würde ich bezweifeln)
C ist, im gegensatz zu den meisten Pascal Dialekten (außer ISO Pascal) eine Standardisierte Sprache, wobei der Standard die ganzen Grundlagen der Sprache Definiert. C ist zwar grundsätzlich eine Hochsprache, aber dennoch extrem Hardware nah, und von daher ist eins der Ziele des C standards, optimale Hardwareunterstützung zu gewährleisten, egal auf welcher Maschine es läuft. Von daher ist der C standard sehr offen gehalten, sodass es so zu sagen nur ein "minimales" set an Anforderungen beschreibt, mit sehr viel raum für Implementationsspezifika.
Die Integer Typen sind davon mit am meisten betroffen, früher mehr als heute, gibt es CPUs die verschiedene Operationen deutlich schneller ausführen können als andere.
Beispiel der typ Char ist definiert als:

An object declared as type char is large enough to store any member of the basic
execution character set. If a member of the basic execution character set is stored in a
char object, its value is guaranteed to be nonnegative. If any other character is stored in
a char object, the resulting value is implementation-defined but shall be within the range
of values that can be represented in that type

Da steht nicht von größe, sondern lediglich das es so groß sein soll um jedes mitglied eines Charactersets darzustellen. Das können 4, 6, 8 16 oder sogar 32 bit sein, je nach dem welches Charakterset Nativ für das entsprechende System ist. Effektiv ist es heutzutage 8 bit, aber wenn man eine neue 6 bit Architektur bauen würde, so würde ISO C das von Haus aus optimal unterstützen.

Auch interesant ist der nächste absatz:

There are five standard signed integer types, designated as signed char, short
int, int, long int, and long long int.

die normalen integer typen, short, int, long und long long sind standardmäßig signed, char allerdings nicht, dafür muss man explizit "signed" schreiben. Der grund dafür ist das Char zur textverarbeitung eingesetzt wird, und dabei die optimale implementierung verwendet werden soll. Auf manchen CPUs sind signed operationen schneller, da wird signed genommen, auf anderen unsigned, da wird unsigned genommen.

Ähnlich sieht es für die anderen Integer typen aus. In C sind die Integertypen tatsächlich nicht in Bitgrößen definiert, sondern über so genannte Limits:

A ‘‘plain’’ int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>).

Ein Integer typ ist also nicht anderes als ein Objekt was eine bestimmte Zahlenreichweite enthalten kann. Wobei INT_MIN/INT_MAX als mindestens +/-(2^15-1) definiert sind. D.h. das einzige was garantiert wird ist das ein int objekt mindestens 15 binär stellen hat, sonst nichts.
Der grund warum das Mindestlimit -(2^15-1) ist statt -2^15 wie mann es bei 2er Komplement erwarten würde ist weil C agnostisch zu dem Verwendeten Sign mechanismus ist. In C 1er Komplement, 2er Komplement, sign and Magnitude, oder jede andere implementation ist möglich, solang mindestens 15 Binärstellen für ganze Zahlen verwendet werden können. Tatsächlich könnte ein C Compiler z.B. auch intern IEE754 Floats (z.B. double) dafür verwenden solange die Mantisse > 15 bits ist.

Ein integer in C ist daher also kein n-bit 2er Komplement bitstring, wie es in vielen anderen Sprachen ist, sondern ein Integer ist ein typ der Zahlen zwischen INT_MIN und INT_MAX halten kann. Was genau intern benutzt wird, kann der COmpiler so entscheiden wie es am besten ist.

Das kann übrigens auch zu lustigen nebeneffekten füren, das schönste was ich mal gesehen habe ist das die overflowdetection komplett wegoptimiert wurde:

Code: Alles auswählen

while (myint > 0) {
  // irgendwas was myint incrementiert bis zum überlauf
}

wurde zu einem "while (true)", weil der Standard überlauf nicht definiert, und eine addition kann einen wert niemals kleiner machen, und von daher ist das eine nach C standard semantisch korrekte optimierung.

Man kann sich natürlich von dem C standard lösen, was nicht Undefiniert ist (z.B. sign mechanismus) sondern Implementationsabhängig (wie die größe von Ints), dann muss man sich aber im Klaren sein das man kein Standard C mehr schreibt, was auf jedem System exakt das selbe tut, sondern das man dann z.B. x86 GCC C schreibt, was unter den im GCC manual spezifizierten eigenschaften auf x86 funktioniert, aber z.B. nicht garantiert unter Clang für ARM64 läuft.

---

Das ist im FPC aber nicht der Fall. Da Pascal nicht den Anspruch hat so low-level flexibel wie C zu sein, hat man in Pascal eine ganz einfache Spezifikation für Zahlen: https://www.freepascal.org/docs-html/ref/refsu4.html

Type Range Size in bytes
Byte 0 .. 255 1
Shortint -128 .. 127 1
Smallint -32768 .. 32767 2
Word 0 .. 65535 2
Integer either smallint or longint size 2 or 4
Cardinal longword 4
Longint -2147483648 .. 2147483647 4
Longword 0 .. 4294967295 4
Int64 -9223372036854775808 .. 9223372036854775807 8
QWord 0 .. 18446744073709551615 8

The integer type is an alias to the smallint type in the default Free Pascal mode. It is an alias for the longint type in either Delphi or ObjFPC mode. The cardinal type is currently always mapped to the longword type.

[...]

Remark In newer Delphi versions, the longint type is platform and CPU dependent. This is not so in FPC, where longint is 32-bit on all platforms.

Damit lässt sich ein FPC programm vermutlich nicht so einfach auf ein 15 bit 1er Komplement Architektur porten lassen, aber einen Tod muss man sterben. Zwar hat man hier auch noch ein bisschen Flexibilität beim "Integer" typ, was daran liegt das der FPC mehrere Sprachmodi/Dialekte unterstützt, aber solang man in einem Dialekt bleibt (z.b. ObjFPC) ist es statisch

PS: C hat das auch später (ich glaube 1989) eingeführt, mit den stdint typen:

7.20.1.1 Exact-width integer types
1 The typedef name intN_t designates a signed integer type with width N , no padding bits, and a two’s complement representation. Thus, int8_t denotes such a signed integer type with a width of exactly 8 bits.
2 The typedef name uintN_t designates an unsigned integer type with width N and no padding bits. Thus, uint24_t denotes such an unsigned integer type with a width of exactly 24 bits.
3 These types are optional. However, if an implementation provides integer types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the signed types) that have a two’s complement representation, it shall define the corresponding typedef names

Wer also in C den typen "int" benutzt, und sich dann wundert das irgendwelche bit operationen nicht funktionieren, ist selbst schuld.

[siro]

@PascalDragon und Warf

Ihr habt euch wirklich nochmal viel Zeit genommen um mich mit Informationen zu versorgen,
dafür möchte ich mich erstmal bedanken.

Die Hintergründe der Integer-Größen liegen tatsächlich völlig anders als ich es bisher angenommen habe.

So habe ich jetzt mal ein Mini Konsolaneprogramm geschrieben und mir die Größe der Integer mit unterschiedlichen Modis angesehen

Code: Alles auswählen

program Project1;

{mode  Delphi}   // hier den entsprechenden Modus eintragen

begin
  Writeln(SizeOf(Integer));
  ReadLn;
end.

Default 4
{$mode TP} 2
{$mode objfpc} 4
{$mode macPas} 2
{mode Delphi} 4

Siro ist natürlich immer Experimentierfreudig.....

Code: Alles auswählen

program Project1;

{$mode objfpc}            { Integer wäre jetzt 4 Bytes }

type integer = ShortInt;  { das geht tatsächlich }

begin
  Writeln(SizeOf(Integer));   { Ausgabe 1 }
  ReadLn;
end.

@Zusatzinfo für warf, wo ich aufs Eis gelegt wurde bei "C"
Ein int in "C" ist ja "normalerweise" ein signed, aber bei Bitdefinitionen nicht
Da musste ich wirklich signed int benutzen...Wurde vom Compiler Hersteller IAR bestätigt.

IAR_INT_Bitfields.jpg (31.7 KiB) 7046 mal betrachtet

.
.
Ich wollte grad schreiben, der Integer hat ja einen eigenen Eintrag im Wiki verdient, aber den gibt es ja schon.
Wobei hier wesentlich mehr Info eingeflossen ist als das Wiki hergibt...

[Mathias]

Ich wollte grad schreiben, der Integer hat ja einen eigenen Eintrag im Wiki verdient, aber den gibt es ja schon.
Wobei hier wesentlich mehr Info eingeflossen ist als das Wiki hergibt...

Dann darfst du es gerne ergänzen.