BigInt.asIntN / .asUintN - wo ist der Sinn?

[TS]

Hello Gunnar,

Zählung der Monate ab 0.

Wenn man so will ist die Zählung der Array-Elemente ab 0 die Ursache.

Das wurde schon sehr früh verkackt. Wieviele Off-by-one-Fehler hätten vermieden werden können, wenn man das richtig gemacht hätte‽

1. Element: a[1]; letztes Element: a[a.length] – so einfach hätte es sein können.

Das liegt daran, dass die (Ordnungszahl * Elementgröße) direkt den Offst im Speicherblock angibt / angab.

Das ist kein Grund, den Unsinn in Hochsprachen so zu machen.

Das Problem liegt in der Entstehensgeschichte der Hochsprachen und der Ratlosigkeit der Entwickler, wie sie einerseits kompatibel bleiben können mit den älteren Versionen und trotzdem z. B. solche Änderungen einführen könnten.

Man könnte in neueren Compilern durchaus eine Zwischenschicht einziehen, die die in der Hochsprache benutze N für die ASM-Ebene auf N-1 zurückrechnet, ähnlich, wie man das beim Rangecheck (Turbo-Pascal) auch schon gemacht hat.

Spätestens bei den 4GL-Sprachen, die meistens als Scriptsprachen daherkommen, und ohnehin keinen Direktzugriff auf die Speicherverwaltung mehr zulassen, wäre das sicherlich möglich gewesen.

Bei PHP z. B. hätte man das mMn durchaus berücksichtigen können. Die einzigen Funktionen, die ich da kenne, die irgendwie noch eine Direktmanipulation der Datenstrukturen zulassen, sind die Funktionen pack() und unpack().

Aber direkt an den RAM lassen die Dich auch nicht heran. Zwischenschicht ist wieder ein "Array", das ja bekanntermaßen keines mehr ist, sondern eher eine Baumstruktur (im Modell). Im Hintergund sind es dann verknüpfte Hashtables mit referenzierten Records. Wenn man darin manuell herupfuschen würde, wäre vermutlich ganz schnell der Ofen aus.

Aber noch eine Frage zum Schluss: wie würdest Du "Dateianfang einer (leeren) Datei" definieren, bzw. wie darauf zugreifen?

Glück Auf
Tom vom Berg