![]() |
AW: Umgang mit Single und Real
Zitat:
|
AW: Umgang mit Single und Real
Zitat:
(P)Char ist ab D2009 ein 2-Byte (besser gesagt (UTF16)) Character. D.h. wenn du mit einem D2009 PChar eine DLL aufruftst die ein 1-Byte PChar erwartet wird diese fast immer nur 1 Zeichen auslesen. |
AW: Umgang mit Single und Real
Falls du das mit den generischen Typen noch nicht ganz verstanden hast ... das sind nur "Umleitungen", bzw. ist ein Alias für einen anderen Typen.
Bis Delphi 2007 und in FreePascal/Lazarus: Char = AnsiChar PChar = PAnsiChar String = AnsiString Ab Delphi 2009 Char = WideChar PChar = PWideChar String = UnicodeString Also genauso wie Real, was aktuell ein Alias für Double ist. |
AW: Umgang mit Single und Real
Dann werde ich bei der Gelegenheit nicht nur Real in Double abändern, sondern gleich noch integer in Longint.
Wenn ich nun aber mit C# arbeite, wo das .net-Framework verwendet wird, sollte ich bei Übergabe von Zeichenketten AnsiString oder doch lieber WideString nehmen? |
AW: Umgang mit Single und Real
Zitat:
Seit bekannt war, daß es bald endlich mal 64 Bit gibt, hab ich spätestens angefangen, den Integer so einzusetzen, wie es gut ist. Also da Integer, wo es mal 64 werden kann und dort wo es 32 Bit bleiben muß, wurde LongInt eingesetzt ... also genau so, wie es mal gedacht war. Im Gegensatz zum PChar hatte der Integer schonmal die 16-32-Bit-Grenze überschritten, also hätte man es da doch besser wissen müssen? Toll, jetzt ist das Integer überall kaputt. PS: Damit sind nun auch alle Integer<>Pointer-Konvertierungen futsch. Zitat:
Der ist eine Umleitung/Kapselung von ![]() ![]() ![]() ![]() Es ist also praktisch in nahezu allen Programmiersprachen verfügbar, welche die WinAPI nutzen. |
AW: Umgang mit Single und Real
Zitat:
![]() Ein managed Umgebung muss sowas unabhängig vom Zielsystem festlegen. Zitat:
![]() |
AW: Umgang mit Single und Real
Danke Euch allen. Jetzt bin ich wieder auf Kurs.
|
AW: Umgang mit Single und Real
Zitat:
Und mit dem aufkommen von Managed Umgebungen hätte man auch ahnen können das diese Mitwachsen irgendwann aufgegeben wird. So gibt es eigentlich keine Bestrebungen den String-Datentyp auf 4-Byte aufzubohren (nötig wäre es ja seit ein paar Jahren seit dem die Unicode Base Plane nicht mehr ausreicht). Glücklicherweise hat sich Delphi hier an den Rest der Programmierwelt angepasst und unter 64-Bit den Integer-Typ bei 4 Byte gelassen. Sonst hätte es in diesem Umfeld wieder größere Probleme gegeben. Zitat:
|
AW: Umgang mit Single und Real
Zitat:
Die Entscheidung Integer bei 32-Bit zu belassen bedeutet gleichzeitig, dass man an manchen Stellen keinerlei Möglichkeit hat, denselben Code für alte und neue Delphiversionen zu benutzen. Hätte man ihn auf 64-Bit mitwachsen lassen, hätte ausschließlich fehlerhafter Code nicht mehr funktioniert. Genau so wie es bei PChar und PAnsiChar / PWideChar der Fall ist. Deshalb halte ich das auch für eine Fehlentscheidung, schlechte Programmierung zu unterstützen und guten Code nicht zu ermöglichen... |
AW: Umgang mit Single und Real
Zitat:
Zitat:
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:21 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz