TArray<string> als const im Record deklarieren

[Dennis07]

Zitat von Uwe Raabe:

Interessant dabei ist, daß man den Alias gar nicht verwenden muss...

LOL.

Zitat von DieDolly:

Zitat:

Kann Delphi nicht auch inzwischen bei statischen Arrays die Länge selbst bestimmen?

Nein.

Streng genommen: Doch, kann es. Das merkst du auch, wenn du versuchst, eine andere Elementanzahl zuzuweisen, als du vorher deklariert hast.

Woran es aber dann scheitert, hat weniger mit der Länge, als mit dem Wertebereich des Schlüsseltypen zu tun, den du verwendest. Delphi kann jeden beliebigen zählbaren Typen als Schlüsseltypen für statische Arrays verwenden. Das muss nicht zwingend ein Zahlenwert weil, ist es nur meistens.
Zur Folge hat dies, dass der Compiler nie genau sagen kann, welchen Wertebereich du für den Schlüssel verwenden willst. Aus kompatibilitätsgründen sind nämlich sowohl negative, als auch lückenhafte Typen sowie Bereichstypen als Schlüssel zulässig. Der Compiler wüsste nie, welchen Bereich er nehmen soll, wenn die Wertemenge von der Gesamtmenge aller Schlüsselmöglichkeiten abweicht.

[DieDolly]

Zitat:

Aus kompatibilitätsgründen

Im Prinzip werden Delphi 10.3-Kunden damit bestraft. Mich interessiert kein älteres Delphi.
Der 10.3 Compiler sollte auch auf 10.3 ausgelegt sein. Abwärtskompatibilität, weg damit. Wer einen älteren Compiler will, soll ein älteres Delphi installieren.

[Daniel]

Zitat von DieDolly:

Abwärtskompatibilität, weg damit.

Wie viele Projekte nennenswerter Größe hast Du zu pflegen? Ich schätze, dass das wenige sein werden.

[Uwe Raabe]

Zitat von Daniel:

Wie viele Projekte nennenswerter Größe hast Du zu pflegen? Ich schätze, dass das wenige sein werden.

[DieDolly]

Das hätte man auch netter formulieren können.
Nur weil man Hobbyprogrammierer ist heißt das nicht, dass man keine großen Projekte zu pflegen hat. Ein Schlag ins Gesicht für alle kleinen Hobbyentwickler direkt vom Administrator des Delphiforums

[Neutral General]

Es war nur eine Frage, kein Schlag ins Gesicht.

[Uwe Raabe]

Zitat von DieDolly:

Abwärtskompatibilität, weg damit. Wer einen älteren Compiler will, soll ein älteres Delphi installieren.

Diese Aussage ist vollkommen realitätsfern! Wenn Delphi nicht so außergewöhnlich abwärtskompatibel wäre, müsste bei einer Umstellung ein enormer Zeit- und Kostenaufwand veranschlagt werden. Der ist auch mit dieser Kompatibilität schon manchmal beträchtlich. Da müssen eine ganze Reihe Entwicklungsumgebungen in realen und virtuellen Maschinen umgestellt werden, alle Build-Rechner brauchen eine neue Delphi-Installation und die Build-Skripte müssen angepasst werden. Während der Umstellung und als Fallback müssen die alten Versionen aber immer noch verfügbar sein. Kommen jetzt noch Code-Änderungen dazu, muss das ganze Projekt auch noch umfassende Tests durchlaufen. Die Kosten für eine solche Umstellung sind schon beträchtlich und übersteigen in der Regel die Update- oder Subscription-Kosten deutlich, von den Gefahren unbemerkter Bugs mal ganz zu schweigen.

[DasWolf]

Zitat von DieDolly:

Das hätte man auch netter formulieren können.
Nur weil man Hobbyprogrammierer ist heißt das nicht, dass man keine großen Projekte zu pflegen hat. Ein Schlag ins Gesicht für alle kleinen Hobbyentwickler direkt vom Administrator des Delphiforums

Es ist egal, wer es schreibt. Ob einfache Mitglieder, der Administrator oder Angelo Merte. Es ist auf jeden Fall sachlich und richtig formuliert.

[Dennis07]

Zitat von DieDolly:

Zitat:

Aus kompatibilitätsgründen

Im Prinzip werden Delphi 10.3-Kunden damit bestraft. Mich interessiert kein älteres Delphi.
Der 10.3 Compiler sollte auch auf 10.3 ausgelegt sein. Abwärtskompatibilität, weg damit. Wer einen älteren Compiler will, soll ein älteres Delphi installieren.

Also das ist direkt mehrfach falsch.

Also, erstens, habe ich doch nirgendwo etwas von "Abwärtskompatibilität" gesagt. Weil es nämlich auch nicht stimmt. Statische Arrays funktionieren in Delphi 10.3.3 noch genau wie unter Delphi 1 (zumindest meines Wissens nach).
Was ich meinte, als ich von Kompatibilität sprach, war eher (und ich dachte eigentlich, dass sich das aus dem gesetzten Kontext ergibt) die Kompatibilität zu allen möglichen Schlüsseltypen/-bereichen.

Integer bzw. LongInt bzw. Int32 ist definiert als ein ganzzahliger, zählbarer Typ mit dem Wertebereich von Succ(MaxInt) .. MaxInt . Er wird als Schlüsseltyp für alle dynamischen Arrays, aber auch für die meisten statischen Arrays benutzt. Woher soll der Compiler jetzt aber wissen, welche Schlüssel du für ein statisches Array benutzen möchtest, dessen Elementezahl sich von der Gesamtzahl aller Schlüssel des Wertebereichs unterscheidet?

Das ist schlichtweg nicht möglich. Deshalb musst du immer einen gesamten Wertebereich als Schlüssel angeben, inklusive Ober-und Untergrenze. Das macht den Schlüssel des Arrays kompatibel mit dem entsprechenden Bereichstypen, den es verwendet (beispielsweise ist der Schlüssel eines Arrays mit der Deklaration array [0..5] of T ein anonymer Inline-Typ, der einen Teilbereich des numerischen Standardtyps Integer abbildet und somit zu allen ganzzahligen Typen kompatibel ist, sofern diese mit Integer kompatibel sind).

Definiert die Untergrenze des Schlüssel-Wertebereichs deshalb ein Offset für die Speicherung der Werte in einem Array?
Nein, der Compiler sorgt dafür, dass die entsprechenden Indizes so umgerechnet werden, dass sie für den Programmierer so dargestellt werden. Tatsächlich aber hat ein statisches Array, dessen Schlüsselbereich bei 256 anfängt, nicht ein 255 lehre Speicherblöcke vorweg.

Was ist der Vorteil?
Vorteile gibt es verschiedene. Es ist zum einen eine Bequemlichkeitsfrage: Ich kann einen Aufzählungstypen als Schlüssel verwenden, ohne mich um dessen Wertebereich kümmern zu müssen. Ich muss nicht einmal einen neuen Unterbereich definieren, sondern kann den Bezeichner des Bereichstypen (zB. ein Enum) direkt als Schlüsseltypen verwenden. Der Compiler kennt dadurch die Ober-und Untergrenze des Arrays und weiß, wie viele Werte es gibt und wo er sie hinpacken muss.

Dann wäre da noch ein praktischer Vorteil: Die Kompatibilität zu aufzählungstypen: Man kann ein array[0..n-1] of Char beispielsweise von und/oder zu einem langen String (AnsiString , String bzw. WideString oder UnicodeString ) oder einem PChar, oder aber einem dynamischen array of Char explizit zuweisen (bei String-Literalen genügt sogar eine implizite Zuweisung, da diese automatisch Zieltypisiert werden können).

[himitsu]

Zitat:

Was ist der Vorteil?

Nein, du musst immer die untere und obere Grenze angeben.
Auch bei array[TIrgendeinEnum] of ... ist der untere Bereich gegeben, denn der Enum ist nunmal so definiert, dass er bei 0 beginnt.

Aber jupp, bei einem Offset der unteren Grenze, da rechnet der Compiler überall beim Speicherzugriff dieses Offset automatisch ein und lässt so den genutzten Speicher bei "0" beginnen.

Zitat:

Wenn Delphi nicht so außergewöhnlich abwärtskompatibel wäre

Leider kann man das inzwschen vergessen.

Hach, erinnert sich noch jemand, wie die Firma beim Turbo-Delphi noch so stolz zeigte wie cool abwärtskompatibel doch alles sei?

Seit Delphi 2009 geht es stark bergab.
Spätestens mit Einführung von NextGen ist Delphi nichtmal mehr in der selbenn Version kompatibel.
denn vor allem AutoRefCount macht es nahezu unmöglich einen kompatiblen Code zu schreiben, der überall läuft.


Ab Januar läuft auch für mich der Support von allem vor Windows 10 aus (Win7 ist tot, Win8 nutzt keiner freiwillig, aber seit Win8 gibt es zuviele nette neue APIs)
und auch der Support für alte Delphis gab ich schweren Herzens explizit auf. (XE* und alles davor wird nur noch implizit unterstützt ... entweder es läuft, oder pech gehabt)
Die neuen wieder "kostenfreien" Delphis haben mir da die Entscheidung abgenommen, da auch ohne Geld Aktuelleres möglich ist.

Bei 64 Bit, da liegt es nicht an Delphi ... hier hatte Intel den Vogel abgeschossen, dass der Gedanke Integer und Pointer passen sich an, nun nicht mehr stimmt und somit so einige Codes mühevoll angepasst werden mussten.