Alle Jahre (Monate) wieder... Zukunft von Delphi

[Furtbichler]

Ganz ehrlich? Ich finde es generell ein no-go, wenn Datentypen in der Entwicklung einer Sprache ihren Aufbau ändern. Wieso hat man das bei 'Real' denn nicht auch gemacht? Nee, da wurde aus purem Zufall (FPU) der Datentyp Single,Double und Extended eingeführt (Gott-Sei-Dank). Und Boolean wurde auch so gelassen, stattdessen gibt es dann WordBool, LongBool.

Wieso war man bei Integer und String so dämlich? Na, Delphi eben. Und jetzt soll mir bloß keiner kommen, das das so sein musste. Musste es nicht. Es gibt für alles eine Lösung.

[jaenicke]

Zitat von Furtbichler:

Ganz ehrlich? Ich finde es generell ein no-go, wenn Datentypen in der Entwicklung einer Sprache ihren Aufbau ändern.

Dafür sind es per Definition Metadatentypen, die per Definition keinen festen Aufbau haben.
Wenn man das braucht, gibt es ja entsprechend die Datentypen, deren Aufbau fest definiert ist.

Da das in der Liste der Datentypen auch eindeutig so definiert ist, hätte es damit eigentlich keine Probleme geben sollen. Das war selbst mir ziemlich am Anfang klar als ich mit Delphi angefangen habe. Ich habe zwar einiges falsch oder ungünstig gemacht und habe mich bei API Aufrufen etwas dumm angestellt (kann man in meinen ersten Posts von vor 10 Jahren vielleicht auch noch sehen ), aber das stand in der Hilfe und war damit auch klar.

Bei Ansi <--> Unicode hatte ich daher in meinen privaten Projekten so gut wie keinen Umstellungsaufwand. Nur bei Integer, wo die Vorgehensweise eben nicht der Dokumentation entsprach, musste ich Anpassungen machen.

[Namenloser]

Zitat von Furtbichler:

Wieso hat man das bei 'Real' denn nicht auch gemacht?

Hat man doch! Heute ist Real äquivalent zu Single, aber ursprünglich hatte Real ein anderes Format. Dieses kann man auch heute noch explizit verwenden, in Form von Real48. Aber weil es auf modernen Prozessoren langsam ist (würde mich nicht wundern, wenn es emuliert werden muss), ist es nicht mehr der Standard-Alias für Real.

[Jumpy]

Hallo,

nur mal aus Neugier, da ich noch nicht so lange dabei bin, das ich mal ein altes Projekt hätte umstellen müssen, bzw. das eine was ich von D6 auf D2010 umgestellt habe hat kaum Probleme gemacht:

Wo liegt denn das Problem bei den Strings oder Integern? Bzw. wann hätte man Probleme damit bekommen? Wenn man mit Pointern arbeitet oder so?

Delphi-Quellcode:

var s:String;
begin
  s:='blub';
  showmessage(s);
end;

wird ja wohl kaum Probleme machen.

[DeddyH]

Zitat von Jumpy:

Wo liegt denn das Problem bei den Strings oder Integern?

http://docwiki.embarcadero.com/RADSt...icode_anpassen

Zitat:

Suchen Sie nach Quelltext, der:

davon ausgeht, dass SizeOf(Char) 1 ist.
davon ausgeht, dass die Länge (Length) eines Strings gleich der Byte-Anzahl in dem String ist.
Strings oder PChars direkt manipuliert.
Strings in oder aus einem persistenten Speicher liest oder schreibt.

Die beiden ersten Annahmen sind für Unicode nicht zutreffend, weil bei Unicode SizeOf(Char) größer als 1 Byte sein kann, und die Länge (Length) eines Strings doppelt so groß ist wie die Anzahl der Bytes. Darüber hinaus muss Code, der in einen persistenten Speicher schreibt oder daraus liest, gewährleisten, dass die korrekte Anzahl von Bytes geschrieben oder gelesen wird, da ein Zeichen evtl. nicht mehr durch ein einzelnes Byte repräsentiert werden kann.

[Mavarik]

Zitat von Jumpy:

Delphi-Quellcode:

var s:String;
begin
  s:='blub';
  showmessage(s);
end;

wird ja wohl kaum Probleme machen.

Ne aber ein

Delphi-Quellcode:

var
  S    : Array [0..255] of Char;
  Name : Shortstring;
begin
  Name := 'Meine Mainformtitle'+#0;
  Move(Name[1],S[0],length(Name));
 ...
end;

schon...

[arnof]

Also ohne alles hier durchzulesen:

viele viele haben noch URALT Versionen aus Borlandzeiten!!!!!!!

Da ich nun auch Komponenten vermarkte ist mir das sehr aufgefallen:

Gestern habe ich erst wieder schreiben müssen, das ich Delphi 3 nicht unterstützte Ich schaue ja immer mal mir die Homepage von Kunden an. Hier stand zu lesen hochmoderne RAD Entwicklungsumgebung, da konnte ich mir das grinsen nicht verkneifen!

50% der Käufer benutzt Delphi 5

[Jumpy]

Zitat:

Delphi-Quellcode:

var
  S    : Array [0..255] of Char;
  Name : Shortstring;
begin
  Name := 'Meine Mainformtitle'+#0;
  Move(Name[1],S[0],length(Name));
 ...
end;

Klingt jetzt bestimmt ketzerisch ist aber echt nicht böse gemeint. Warum macht man sowas?
Ich hab ähnliches schon benutzt um Buffer oder variable Records oder sowas, die man von API-Funktionen zurückkriegt auszulesen, aber sonst?
Wie gesgagt echt nicht böse gemeint.

Und ist das bei den Integern genauso? Also das es letztlich damit zu tun hat wie die gespeichert werden?

[mkinzler]

Das Problem beim Integer ist anders gelagert. Er war eigentlich ein "wachsender" Typ; also ein Typ, der sich an die Plattform anpasst ( 16-Bit-Exe: 16Bit; 32-Bit-Exe: 32Bit) Für diesen Zweck haben ihn Viele verwendet. Mit Einführung des 64-Bit Compilers wurde der Typ aber auf 32Bit festgeschrieben und ein neuer virtueller Typ NativeInt eingeführt, der wächst. Alle die sich darauf verlassen haben, das ein Integer immer die Breite der Plattform hat, mussten dann ihren Code ändern.

[Delphi-Laie]

Zitat von mkinzler:

Das Problem beim Integer ist anders gelagert. Er war eigentlich ein "wachsender" Typ; also ein Typ, der sich an die Plattform anpasst ( 16-Bit-Exe: 16Bit; 32-Bit-Exe: 32Bit) Für diesen Zweck haben ihn Viele verwendet. Mit Einführung des 64-Bit Compilers wurde der Typ aber auf 32Bit festgeschrieben und ein neuer virtueller Typ NativeInt eingeführt, der wächst. Alle die sich darauf verlassen haben, das ein Integer immer die Breite der Plattform hat, mussten dann ihren Code ändern.

Ist es mit Cardinal nicht genauso?

Ich kann mich erinnern, das früher schon moniert zu haben, daß eine festgelegte - scheinbar für alle Ewigkeiten gültige - Marschrichtung schon beim nächsten Wechsel der Bitanzahl wieder fallengelassen wurde.