AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Hinweise


TArray<string> als const im Record deklarieren

Ein Thema von DieDolly · begonnen am 5. Dez 2019 · letzter Beitrag vom 15. Dez 2019
Antwort Antwort
Seite 2 von 3     12 3   
Dennis07

Registriert seit: 19. Sep 2011
Ort: Deutschland
435 Beiträge
 
Delphi 10.3 Rio
 
#11

AW: TArray<string> als const im Record deklarieren

  Alt 6. Dez 2019, 01:37
Interessant dabei ist, daß man den Alias gar nicht verwenden muss...
LOL.

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.
Dennis
  Mit Zitat antworten Zitat
DieDolly

Registriert seit: 22. Jun 2018
1.619 Beiträge
 
#12

AW: TArray<string> als const im Record deklarieren

  Alt 6. Dez 2019, 08:13
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.
  Mit Zitat antworten Zitat
Daniel
(Administrator)

Registriert seit: 30. Mai 2002
Ort: Hamburg
15.336 Beiträge
 
Delphi 10.4 Sydney
 
#13

AW: TArray<string> als const im Record deklarieren

  Alt 6. Dez 2019, 08:16
Abwärtskompatibilität, weg damit.
Wie viele Projekte nennenswerter Größe hast Du zu pflegen? Ich schätze, dass das wenige sein werden.
Daniel R. Wolf
Admin Delphi-PRAXiS
mit Grüßen aus Hamburg
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe
Online

Registriert seit: 20. Jan 2006
Ort: Lübbecke
7.903 Beiträge
 
Delphi 10.4 Sydney
 
#14

AW: TArray<string> als const im Record deklarieren

  Alt 6. Dez 2019, 08:29
Wie viele Projekte nennenswerter Größe hast Du zu pflegen? Ich schätze, dass das wenige sein werden.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
DieDolly

Registriert seit: 22. Jun 2018
1.619 Beiträge
 
#15

AW: TArray<string> als const im Record deklarieren

  Alt 6. Dez 2019, 08:37
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
  Mit Zitat antworten Zitat
Benutzerbild von Neutral General
Neutral General

Registriert seit: 16. Jan 2004
Ort: Bendorf
5.151 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#16

AW: TArray<string> als const im Record deklarieren

  Alt 6. Dez 2019, 09:33
Es war nur eine Frage, kein Schlag ins Gesicht.
Michael
"Programmers talk about software development on weekends, vacations, and over meals not because they lack imagination,
but because their imagination reveals worlds that others cannot see."
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe
Online

Registriert seit: 20. Jan 2006
Ort: Lübbecke
7.903 Beiträge
 
Delphi 10.4 Sydney
 
#17

AW: TArray<string> als const im Record deklarieren

  Alt 6. Dez 2019, 09:48
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.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
DasWolf

Registriert seit: 7. Jun 2016
Ort: Neubrandenburg
59 Beiträge
 
Delphi 10.1 Berlin Professional
 
#18

AW: TArray<string> als const im Record deklarieren

  Alt 6. Dez 2019, 09:48
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.
  Mit Zitat antworten Zitat
Dennis07

Registriert seit: 19. Sep 2011
Ort: Deutschland
435 Beiträge
 
Delphi 10.3 Rio
 
#19

AW: TArray<string> als const im Record deklarieren

  Alt 6. Dez 2019, 11:11
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).
Dennis
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
36.702 Beiträge
 
Delphi 10.4 Sydney
 
#20

AW: TArray<string> als const im Record deklarieren

  Alt 8. Dez 2019, 18:17
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 19:43 Uhr.
Powered by vBulletin® Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2020 by Daniel R. Wolf