plattformabhängigen Integertypen LongInt und LongWord

[TiGü]

Zitat von Delphi-Laie:

Zitat von Uwe Raabe:

Meinst du sowas?

Sicher.

Es kommen mit jeder Bitanzahlverdoppelung native Integertypen - und dann noch mit eigenem Namen - hinzu, sodaß es immer mehr werdne un das Chaos immer größer wird.

Joah, vier signed Typen und vier unsigned Typen sind schon echtes Chaos...

Da reicht eine Hand nicht mehr zum Abzählen, muss man die zweite mit hinzunehmen.

[Delphi-Laie]

Zitat von TiGü:

Joah, vier signed Typen und vier unsigned Typen sind schon echtes Chaos...

Da reicht eine Hand nicht mehr zum Abzählen, muss man die zweite mit hinzunehmen.

Byte, Word, Integer, ShortInt, SmallInt, Cardinal, Int64, LongInt, LongWord, NativeInt, NativUInt...

So aus dem Stegreif. Sind jetzt schon 11. Wer zählen kann, ist klar im ...

[Uwe Raabe]

Zitat von Delphi-Laie:

Es kommen mit jeder Bitanzahlverdoppelung native Integertypen - und dann noch mit eigenem Namen - hinzu,

Dann nimm doch die oben gezeigten. Bei denen ist die Größe ja durch die Zahl im Namen eindeutig. Da die bereits in System.pas deklariert sind, muss man da auch nicht noch selbst was erfinden.

[Delphi-Laie]

Zitat von Uwe Raabe:

Bei denen ist die Größe ja durch die Zahl im Namen eindeutig.

Genau das war doch meine Aussage.

Wie man es konsequent und übersichtlich hätte machen können, beschrieb ich schon weiter vorn.

[TiGü]

Zitat von Delphi-Laie:

Zitat von TiGü:

Joah, vier signed Typen und vier unsigned Typen sind schon echtes Chaos...

Da reicht eine Hand nicht mehr zum Abzählen, muss man die zweite mit hinzunehmen.

Byte, Word, Integer, ShortInt, SmallInt, Cardinal, Int64, LongInt, LongWord, NativeInt, NativUInt...

So aus dem Stegreif. Sind jetzt schon 11. Wer zählen kann, ist klar im ...

Mit Int64 und UInt64 komme ich auf zwei mal fünf...der Rest sind Aliasse.
Weißt du, was ein Alias ist?

Selbst wenn es zwanzig oder dreißig wären...na und? Überfordert dich das? Wirklich?

[Uwe Raabe]

Zitat von Delphi-Laie:

Wie man es konsequent und übersichtlich hätte machen können, beschrieb ich schon weiter vorn.

Hat man aber doch! Oder woher glaubst du, habe ich die Deklarationen?

[Delphi-Laie]

Zitat von Uwe Raabe:

Zitat von Delphi-Laie:

Wie man es konsequent und übersichtlich hätte machen können, beschrieb ich schon weiter vorn.

Hat man aber doch! Oder woher glaubst du, habe ich die Deklarationen?

Nun, dann müssen himitsu und meine Wenigkeit sich eben geirrt haben. Ist alles eben doch konsequent, logisch und einheitlich.

[Der schöne Günther]

Und ich dachte Entwickler könnten nur im unendlichen Tabs gegen Leerzeichen-Krieg so emotional werden.

[himitsu]

Konsequent und logisch, aus Sicht der jeweiligen Plattformen vielleicht, aber aus Sicht eines Codes für Multiplatform ist es das IMHO nicht.
Und vorallem auch nicht aus Sicht der "uns" bekannten Muster von Typen. (wegen der Wiederverwendbarkeit alter Codes / uns = Windows+Pascal)

Gut, dass Integer und Cardinal nun nicht mehr systemabhängig sind, das kann man verkraften, wenn man einfach still und heimlich vergisst wie es zu Zeiten von 8 und 16 Bit mal war.
(dabei war Delphi im Jahre 2006 noch sooooooooooooo stolz auf seine berühmte Abwärtskompatibilität)

Aber es war nunmal früher so, dass LONG = 32 und LONG LONG = 64, also LongInt immer 32 und nicht plötzlich 64, auch auf 64 Bit-Systemen (außer im Windows 64).
Was hätte dagegen gesprochen den LongInt 32 zu lassen und wegen MacOS stattdessen z.B. ein OptimalInt zu erfinden?



Genauso gibt es keinen plausiblen Grund, warum obj.Free unter ARC nicht Free macht, sondern einfach "fahrlässig" komplett ignoriert wird (garnichts macht).
Hier gab es aus den anderen Systemen ein Äquivalent, also hätte man DisposeOf auch als Alias für Free hinzufügen können, weil es dort das Selbe wie ohne ARC das Free macht, um leichter C#-Code nach Delphi portieren zu können,
und stattdessen ein FreeLater (oder so), als Äquivalent zum obj:=nil der bekannten GarbageCollector-Systeme.

[Der schöne Günther]

Die Memory-Management-Geschichte ist eine Katastrophe, das sehe ich auch so.

Aber das Problem mit den Typbezeichnungen verstehe ich ehrlich gesagt immer noch nicht. Angenommen man erstellt Code in Zeiten als Delphi rein "Windows only" war. Der gleiche Code tut doch auch heute, egal ob Windows 32 oder 64-Bit immer noch das absolut richtige, oder?

Das man auf anderen Plattformen gleiche/ähnliche Namen für teilweise andere Datentypen erfunden hat kann man doch Delphi nicht anlasten, oder?


PS: Wenn ich z.B. etwas plattformspezifisches mit der WinApi mache nehme ich auch immer die entsprechenden Typen (wie DWORD oder ULONG) statt den "High-Level-Typen" (wie Cardinal) die grade jetzt in meiner aktuellen Konfiguration drauf passen würden. Ist das nun richtig oder falsch?