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

[jaenicke]

Zitat:

Zitat von mkinzler (Beitrag 1242662)

String ist ein virtueller Typ; wenn man einen bestimmten will muss man eine konkreten Stringtyp ( AnsiString, Unicodestring verwenden!

Wenn man sich denn hätte auf so etwas verlassen können, würde es Sinn machen seinen Code entsprechend zu schreiben. (Mache ich auch)
Das habe ich bei Integer aber auch gemacht... und dann kam 64-Bit und rumms, alles neu schreiben.

[mkinzler]

Beim Integer haben sie sich nicht daran gehalten, obwohl Integer auch ein "virtueller" Typ war.
Darum schrieb ich ja, dass es in diesem Fall "ausnahmsweise" nicht an Delphi/EMBT liegt.
Das der Integertyp sicht mehr wächst und der geänderte Startindex beim String (nextgen) schon.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1242764)

Beim Integer haben sie sich nicht daran gehalten, obwohl Integer auch ein "virtueller" Typ war.

Beim Integer hat man halt das gemacht was der Rest der Sprachen-Welt auch gemacht hat. Unter 64-Bit integer trotzdem bei 32-Bit gelassen.
Der Aufschrei/Ärger wäre größer wenn Delphi hier den eigen/eigentlich konsequenteren Weg gegangen wäre.

[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. :wall: 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:

Zitat von Furtbichler (Beitrag 1242789)

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 :oops:), 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:

Zitat von Furtbichler (Beitrag 1242789)

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.

[Bernhard Geyer]

Zitat:

Zitat von Furtbichler (Beitrag 1242789)

Wieso war man bei Integer und String so dämlich? Na, Delphi eben. :wall:

MS hat es mit C genau so gemacht. Integer ist gewachen und auch unter 64-Windows ist der Integer jetzt 32-Bit lang. Na, Microsoft eben. :wall:
Und wie ist es mit CString in C++? 8 Bit wenn nicht Unicode und 16 Bit (hier geht man nicht darauf ein ob jetzt UCS-2 oder UTF-16 verwendet wird (man nimmt halt das was das OS nimmt, also NT: UTC-2 und danach UTF-16)

[DeddyH]

Zitat:

Zitat von Jumpy (Beitrag 1242797)

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:

Zitat von Jumpy (Beitrag 1242797)

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...