Na, schon Delphi XE gekauft?

[ralfschwalbe]

Genau, dann hast Du keine Probleme....

Aber wer hat vor 10 Jahren einen Record mit AnsiChar oder LongWord gebaut?

Bei mir ist (fast) überall folgendes zu finden:

Code:

tMyRec = record
a1 : array[1..24] of char;
a2 : array[1..20] of char;
c1 : cardinal;
usw...
end;

Durch Compilerschalter des Projektes ({$A1}) liegt alles schön hintereinander. Da kann man nicht einfach so weiterarbeiten (mit Delphi ab 2009 meine ich). Da will ALLES umgestellt werden!

da war einer schneller... ;-)

[mkinzler]

Deshalb gibt es ja generische Tapen und fixe Typen. Die generischen sind veränderlich, die fundamentalen bleiben konstant!

Wer jetzt generische nimmt, barucht sich nicht zu wunder, wenn diese sich ändern. das ist ihre Natur.

Code:

Generische Typen:
    -string

    -Integer
    -Cardinal

Fixe (fundamentale) Typen:
    -ShortString
    -AnsiString
    -UnicodeString

    -Shortint (Int8)
    -Smallint (Int16) 
    -Longint (Int32) 
    -Int64 
    -Byte ( UInt8) 
    -Word ( UInt16) 
    -Longword (UInt32) 
    -UInt64

Jetzt soll der Integer als bisher generischen Typ zu einem fundamentalen werden. das finde ich nicht gut, da es den entsprechenden fundamentalen Typ (Longint) und einen Alias (Int32) schon gibt!

[ralfschwalbe]

Es soll nichts zu etwas anderen werden. Es soll nur angemerkt werden, dass es Umstände gibt, wo das Sch... ist. Und sag bitte nicht "Ihr habt es alle gewusst!" Wer hat vor 10 Jahren dran gedacht, das es wirklich mal 64bit OS gibt, wo der Integer keine 4 Byte mehr hat, oder das ein Char mehr als 1 Byte platz braucht.

[mkinzler]

Deshalb bekommt man ja bei einer neuen Delphiversionen, das Nutzungsrecht für ältere hinzu.

Man darf sich halt nur auf das verlassen, was zugesichert ist. Wer einen generischen Typ verwendet muss sich bewusst sein, das der sich ändern kann.

Aber man hat ja ein Einsehen. Der generische Integer wird ja abgeschafft. Was bedeutet, dass nicht die wenigen Programme, die von einer festen Breite ausgehen angepasst werden müssen, sondern allen anderen, welche auch ohne Anpassung funktionieren würden!!

[Bernhard Geyer]

Zitat:

Zitat von ralfschwalbe (Beitrag 1046624)

Wer hat vor 10 Jahren dran gedacht, ... oder das ein Char mehr als 1 Byte platz braucht.

Also ich war vor 8 Jahren darüber eine große Delphi (6) Anwendung von String auf Widestring umzustellen :mrgreen:

[himitsu]

Zitat:

Zitat von ralfschwalbe (Beitrag 1046624)

Wer hat vor 10 Jahren dran gedacht, das es wirklich mal 64bit OS gibt, wo der Integer keine 4 Byte mehr hat, oder das ein Char mehr als 1 Byte platz braucht.

Wer so "alt" ist, der hat auch schon (fast) die 16-nach-32-Bit-Umstellung mitgemacht ... und genau dann hätte man sich denken können, daß es irgendwann mal weitergehen kann :zwinker:


@Sherlock: Ich hab nie behauptet, daß man diese generischen Typen nicht verwenden soll.

Innerhalb der Anwengung ist es nähmlich sehr gut, denn so würde mit dem Umstieg auf Unicode oder eben 64 Bit (falls sich der Integer doch noch ändert) automatisch umgestellt.

Wenn es aber darum geht Daten an andere Programme zu übergeben, wozu auch die Speicherung zählt, wenn sich zwischendurch mal die Struktur des Programmes ändern kann, bis dieses dann wieder ausgelesen wird,
dann sollte man eben nur fundamentale Typen verwenden, da diese gleich bleiben, auch wenn sich die Programmstruktur ändert.

[mleyen]

Zitat:

Zitat von mkinzler (Beitrag 1046625)

Was bedeutet, dass nicht die wenigen Programme, die von einer festen Breite ausgehen angepasst werden müssen, sondern allen anderen, welche auch ohne Anpassung funktionieren würden!!

Die machen´s doch gerade weil man weder Integer auf LongInt, noch Integer auf BigSuperGr8Int anpassen muss.

[ralfschwalbe]

@Bernhard Geyer: Dann hast Du Glück gehabt. Gabs ne Anforderung nach mehreren Sprachen oder hast Du nur aus Langweile getan? :wink: Und zum Thema "Integer bleibt 4 Byte"; hätte man das mit string und Char nicht auch so machen können? :roll::lol::stupid:

Verzeihung, ich schweife schon wieder ab...;-) Ketzerei, Ketzerei...

[mkinzler]

Zitat:

Zitat von mleyen (Beitrag 1046631)

Zitat:

Zitat von mkinzler (Beitrag 1046625)

Was bedeutet, dass nicht die wenigen Programme, die von einer festen Breite ausgehen angepasst werden müssen, sondern allen anderen, welche auch ohne Anpassung funktionieren würden!!

Die machen´s doch gerade weil man weder Integer auf LongInt, noch Integer auf BigSuperGr8Int anpassen muss.

Die Natur von generischen Tpen ist, dass diese automatisch den apssenden Tap haben. Bei Integertypen den der Plattform. Integer in einem 16Bit OS war 16Bit, bei einem 32Bit OS 32Bit. Jetzt würde ich7man erwarten, das der bei einem 64Bit OS 64Bit hat; wäre dann aber nicht mehr so, da Integer jetzt ein weiterer Alias von LonInt wäre. Will man, wie meisst gewünscht immer die Standradbreite haben, muss man dann Integer durch Int64 oder einem neuen generischen Typ (NativeInt) ersetzen.

[himitsu]

Ich finde es ehrlich gesagt blöde, daß solche Änderungen in der Natur der Typen, wie mit dem Integer, gemacht werden sollen.
Ebenso die Idee Char weiterhin als AnsiChar zu belassen.
Und das nur damit weniger von den Unmassen rumheulen, welche "fehlerhaft" Codes verwenden, der nach soeiner Umstellung nicht mehr laufen würde.

Klar, für die fehlerhaften Altlasten wäre das super, aber für "ordentlich" programmierte Codes oder für Neuprogrammierungen ist das ein graus.

Man nehme nur mal die kranken Funktionen wie AnsiLowerCase, welche jetzt urplötzlich Unicode sind, obwohl sie ANSI heißen. :wall: