Na, schon Delphi XE gekauft?

[himitsu]

@gammatester: OK, dann isses eben seit D2 so.

Zitat:

Zitat von Sherlock (Beitrag 1046686)

Den Teil hab ich wohl in der D5 Hilfe überlesen...und damals war die noch wirklich ausführlich.

Einige Auszüge aus der OH meines Delphi 4 ... nur damit keiner behaupten kann, er wußte von nichts.

Zitat:

Zitat von Reelle Typen

Der generische Typ Real ist in der aktuellen Implementation mit dem Typ Double identisch.

Zitat:

Zitat von Integer-Typen

Es gibt zwei generische Integer-Typen: Integer und Cardinal. Diese Typen sollten, wenn möglich, immer verwendet werden, da sie die optimale Ausführungsgeschwindigkeit für die zugrundeliegende CPU und das Betriebssystem gewährleisten

Zitat:

Zitat von String-Typen

Das reservierte Wort string funktioniert wie ein generischer Typbezeichner.

Zitat:

Zitat von Hansa

Was predigst Du ? Bzw. wo , wie was ? :mrgreen: Ich sage jedenfalls : integer oder sonstwas hat 4 Byte. Basta. Auch unter Win128. Dann können sie ruhig kommen mit Bigint, SuperBigInt etc. :mrgreen:

Zitat:

Zitat von himitsu

Na das mit dem Integer und den sich "ändernden" Typen.

Zitat:

Zitat von himitsu (Beitrag 1046616)

Mavarik: Wenn deine Records (welche gespeichert oder übertragen werden) nur native Typen (LongInt statt Integer, LongWord statt Cardinal, Double statt Real und AnsiChar/WideChar statt Char) verwenden und auch noch "packed" sind, bzw. wenn eine bestimmte Ausrichtung explizit vorgegeben ist, dann gibt es keine Probleme, selbst wenn sich der Integer ändert oder nicht oder wenn nun Unicode verwendet wird.

Zitat:

Zitat von himitsu (Beitrag 1046630)

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.

.........

Die generischen (veränderlichen) Typen wurden mal eingeführt, da sie sich an das Betriebssystem, bzw an den Compiler für dieses System anpassen und dort die "optimalen" Typen nutzen, welche nativ vom System unterstützt werden.

In Unicodesystemen (eigentlich seit WinNT) ist die API nunmal nativ Unicode, also sind in einem Compiler dafür natürlich die Stantardtypen auch auf Unicode eingestellt.
> Char=WideChar PChar=PWideChar und String=(WideString)UnicodeString

Unter einem 16 Bit Windows ist der Integer halt 16 Bit, bei einem 32 Bit Windows eben 32 Bit und für ein 64-Bit-System wäre dieser nunmal 64 Bit. (entsprechend den Registergrößen der CPU)

Daß Delphi leider immer "etwas" hinterherhinkt, ist leider eine blöde Tatsache ... also weswegen sich leider alle so an die zu lange "statisch" erscheinenden 32 Bit und Ansi gewöhnen konnten.
(Mit Win2000 ist Windows seit dem Jahr 2000 im Konsumerbereich Unicode und Delphi schaffte erst 2008, mit Delphi 2009, den Sprung.
Windows und die CPUs sind auch schon seit vielen Jahren 64 Bit und Delphi hat auch das noch nicht geschaft.
OK, XP64 kann man vergessen, aber seit Vista im Jahre 2007 hält nun auch immer mehr 64 Bit im Konsumerbereich einzug und Delphi hat es wiedermal immernoch nicht hinbekommen. (wenn ich das jetzt hochrechne, dann komm ich für den 64-Bit-Delphi-Compiler auf das Jahr 2015-2017)

(weil ich grad so schön am schreiben war ... hier nochmal für die Anderen)

In einigen Spielekonsolen sind wir schon seit Jahren über die 64 Bit hinaus, also könnte/wird dieses bestimmt auch irgendwann in den PCs Einzug halten.
Wenn die PCs dann mal 128/256 Bit haben werden (PS: Die Grafikkarten machen das doch anscheinend schon, und immer mehr Programmierer verschieben schon einige Berechnungen in die GPU), dann wird Delphi hoffentlich auch schon ein Weilchen 64-Bittig sein.

[mkinzler]

Das mit dem String hat ja nichts mit 16/32Bit zu tun, sondern ob es der "alte" Pascalstring ist, bei dem an der ersten Stelle, die Länge stand und der deshalb nur maximal 255 Zeichen lamg sein konnte oder der in Delphi eingeführte "neue" String mit einer variablen Länge.

[MEissing]

Zitat:

Zitat von Win32.API (Beitrag 1046693)

Zitat:

Zitat von MEissing (Beitrag 1046676)

Du sprichst in Rätseln...

Einfach a<( in die IDE tippen/kopieren und im Taskmanager beobachten.

Ah.

Das Rätsel lüftet sich....?

Du meinst im Quellcode-Editor?
Du meinst im Adressfeld der Willkommens-Seite?
Du meinst Layout-Feld?
[...]

[Win32.API]

Lass ich mir Heute wirklich alles aus der Nase ziehen? :stupid:

Im Quelltext-Editor.

[Mavarik]

WOW..

Jetzt geht es aber a hier...

Für mich gibt es ÜBERHAUPT keinen Grund einen bestehenden Datentypen zu ändern...

Schon bei der Umstellung von String zu Longstring... Ich fand das als eine unverschämtheit! Aber wenigstens gabs es {H-} jede 2. Unit hat das noch...

Neuer Datentypen neuer Name... Kann doch nicht so schwer sein...
Das gleiche gilt für Routinen mit geänderter Parameterliste.

Oder geänderte Type sage nur SearchRec...

Aber das ist schnee von Gestern das hat man ja im laufe der Zeit umgebaut...
Aber ich hatte gehoft das die schlauer werden...

Kann mich gut noch an eine Road-Show erinnern. Der Aufmacher war glaube ich:
"Schaut mal gleicher Sourcecode für Delphi 4 5 & 6..." Das waren noch Zeiten...


Mavarik :coder:

[himitsu]

@Mavarik: Seit der Umstellung vom "ShortString" (früher String) auf AnsiString, wurde doch schon gesagt, daß der "neue" String ein generischer Typ ist.
Also war es auch Klar, das sich der String irgendwann mal ändern könnte und nur der AnsiString so bleibt, wie er ist.

Es wurde also absolut kein "bestehender Datentyp" geändert. (seit D2 und in Bezug auf Integer/Real/Char)
Von der Definition her ist der String immernoch generisch und er hatte sich intern an das Unicode angepaßt.

Was wird nur passieren, wenn dann mal auf UCS4 umgestellt wird und der Char dann mal 4 Byte groß ist. :roll:

Zitat:

Zitat von Mavarik (Beitrag 1046700)

Kann mich gut noch an eine Road-Show erinnern. Der Aufmacher war glaube ich:
"Schaut mal gleicher Sourcecode für Delphi 4 5 & 6..." Das waren noch Zeiten...

Das ist doch immernoch so?
Also wenn man die passenden/richtigen Datentypen verwendet hatte und nicht irgendwelche Pointeroperationen mit "falschen" Datengrößen verwendet.

[Bernhard Geyer]

Beim Typ "String" ist die Arbeit bezüglich Portierung (für Codegear) einfacher wenn man String = Wide/Unicodestring nimmt.
Alle API in der Unicode-Win32API sind nunmal mit PWidechars statt PChars definiert. D.h. hätte man einen anderen Typ genommen hätte man alle WinApi-Bibliotheken (Windows.pas, ...) entsprechend anpassen müssen. Die Frage ist wieviel Code dadurch dann nicht mehr gegangen wäre ist auch offen.

Bei Integer ist glaube ich das gleiche Problem. Wenn nun "der Rest der Welt" beim Sprung auf 64-Bit die länge von Integer gleich lässt müsste ebenfalls jede API-Funktion kontrolliert bzw. angepaßt werden.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1046702)

Was wird nur passieren, wenn dann mal auf UCS4 umgestellt wird und der Char dann mal 4 Byte groß ist. :roll:

Glaube ich nicht das das kommt. WinAPI/Java/.NET laufen alle mit UTF16 und können damit mehr als die Baseplane von Unicode. Es besteht also keine Notwenigkeit hier auf UCS4 zu wechseln (Lazarus hat sich selbst UTF16 gespart und läuft mit UTF8 obwohl das bedeutet das man mit fast jeder Schnittstelle nach UTF16 wandeln muss).

[Namenloser]

Zitat:

Zitat von Mavarik (Beitrag 1046700)

Kann mich gut noch an eine Road-Show erinnern. Der Aufmacher war glaube ich:
"Schaut mal gleicher Sourcecode für Delphi 4 5 & 6..." Das waren noch Zeiten...

Wenn man die richtigen Datentypen verwendet hat, gilt das auch in Zukunft noch, selbst für 64 Bit. Wer sich darauf verlassen hat, dass generische Typen immer die gleiche Größe behalten, ist selbst schuld - nirgens steht, dass ein Integer immer 32 Bit breit sein muss. Wenn du das dennoch als gegeben hinnimmst, bindest du dich logischerweise eben an eine bestimmte Plattform. Es ist dann nicht die Schuld des Compilerherstellers, wenn dein Code, der unter einer Plattform "zufällig" funktioniert hat, auf einer anderen versagt.
Oder beschwerst du dich auch, wenn dein X86 Inline-Assembler nicht funktioniert, wenn du hypothetischerweise irgendwann mal für's iPhone kompilieren willst?

[gammatester]

Zitat:

Zitat von mkinzler (Beitrag 1046696)

Das mit dem String hat ja nichts mit 16/32Bit zu tun, sondern ob es der "alte" Pascalstring ist, bei dem an der ersten Stelle, die Länge stand und der deshalb nur maximal 255 Zeichen lamg sein konnte oder der in Delphi eingeführte "neue" String mit einer variablen Länge.

Noch einmal: Diesen "neuen" String, der angeblich mit Delphi eingeführt wurde, gibt es in Delphi 1 nicht! Natürlich bleibt es Dir unbenommen, zu behaupten Delphi 1 sei kein Delphi :)