AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Umgang mit Single und Real

Ein Thema von Gargamel · begonnen am 3. Jun 2012 · letzter Beitrag vom 4. Jun 2012
Antwort Antwort
Seite 2 von 3     12 3   
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.103 Beiträge
 
Delphi 10.4 Sydney
 
#11

AW: Umgang mit Single und Real

  Alt 3. Jun 2012, 21:21
Genauso wie damals der Integer von 16 auf 32 Bit wuchs und eigentlich auch auf 64 Bit gewachsen währe ... währe da nicht ein I*** auf die Idee gekommen den einzufrieren und stattdessen z.B. den NativeInt zu erfinden.
Was hat bloss diese I*** bei MS und ANSI (?) geritten Integer nicht mehr mitwachen zu lassen. Vermutlich das Problem das das Mitwachen von Int zu 8 Byte zu viel zu übearbeitenden bedeutet hätte ...
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.103 Beiträge
 
Delphi 10.4 Sydney
 
#12

AW: Umgang mit Single und Real

  Alt 3. Jun 2012, 21:23
Aber das mit PChar verstehe ich nicht. Die Übergabe von Zeichenketten hatte auf diese Weise immer sehr gut funktioniert.
(P)Char ist bei D2007 und älter ein 1-Byte-Character .
(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.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
40.504 Beiträge
 
Delphi 11 Alexandria
 
#13

AW: Umgang mit Single und Real

  Alt 3. Jun 2012, 21:24
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list

Geändert von himitsu ( 3. Jun 2012 um 21:29 Uhr)
  Mit Zitat antworten Zitat
Gargamel

Registriert seit: 19. Mär 2007
171 Beiträge
 
#14

AW: Umgang mit Single und Real

  Alt 3. Jun 2012, 21:27
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?
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
40.504 Beiträge
 
Delphi 11 Alexandria
 
#15

AW: Umgang mit Single und Real

  Alt 3. Jun 2012, 21:29
Zitat:
Vermutlich das Problem das das Mitwachen von Int zu 8 Byte zu viel zu übearbeitenden bedeutet hätte ...
Also genauso wie beim PChar von ANSI zu Unicode?

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.


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?
WideString ist kein eigener Delphityp.
Der ist eine Umleitung/Kapselung von MSDN-Library durchsuchenSysAllocStringLen, MSDN-Library durchsuchenSysReAllocStringLen, MSDN-Library durchsuchenSysFreeString und MSDN-Library durchsuchenSysStringLen, also im Grunde perfekt geeignet, für eine systemübergreifende Kommunikation, abgesehn von PAnsiChar und PWideChar und wird z.B. auch von vielen COM-Schnittstellen genutzt.
Es ist also praktisch in nahezu allen Programmiersprachen verfügbar, welche die WinAPI nutzen.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list

Geändert von himitsu ( 3. Jun 2012 um 21:41 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.103 Beiträge
 
Delphi 10.4 Sydney
 
#16

AW: Umgang mit Single und Real

  Alt 3. Jun 2012, 21:44
Dann werde ich bei der Gelegenheit nicht nur Real in Double abändern, sondern gleich noch integer in Longint.
Brauchst nicht. In C# (und Java) ist integer immer 32-Bit (http://msdn.microsoft.com/en-us/libr...(v=vs.80).aspx).
Ein managed Umgebung muss sowas unabhängig vom Zielsystem festlegen.

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?
Widestring. Damit hast du den gleichen UTF-16 der in NET und Java eingesetzt wird. (http://msdn.microsoft.com/en-us/libr...(v=vs.71).aspx)
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Gargamel

Registriert seit: 19. Mär 2007
171 Beiträge
 
#17

AW: Umgang mit Single und Real

  Alt 3. Jun 2012, 21:46
Danke Euch allen. Jetzt bin ich wieder auf Kurs.
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.103 Beiträge
 
Delphi 10.4 Sydney
 
#18

AW: Umgang mit Single und Real

  Alt 3. Jun 2012, 21:48
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.
Dann warst du vermutlich einer der wenigen Programmierer der sowas gemacht hat.
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.

PS: Damit sind nun auch alle Integer<>Pointer-Konvertierungen futsch.
Sowas macht man ja auch nicht (auch wenn es manchmal der einfachste weg ist/war)
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
8.503 Beiträge
 
Delphi 10.4 Sydney
 
#19

AW: Umgang mit Single und Real

  Alt 3. Jun 2012, 22:21
PS: Damit sind nun auch alle Integer<>Pointer-Konvertierungen futsch.
Sowas macht man ja auch nicht (auch wenn es manchmal der einfachste weg ist/war)
Das ist aber manchmal der einzige Weg gewesen. NativeInt gab es ja früher noch nicht.

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...
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.103 Beiträge
 
Delphi 10.4 Sydney
 
#20

AW: Umgang mit Single und Real

  Alt 4. Jun 2012, 00:06
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.
Wieso das? Es verbietet dir keiner ein NativeInt = Integer für Pre-XE2 zu definieren.

Hätte man ihn auf 64-Bit mitwachsen lassen, hätte ausschließlich fehlerhafter Code nicht mehr funktioniert.
Blöd wäre nur gewesen das dieser fehlerhafte Code sehr viel häufiger und auch teilweise sehr versteckt Portierungsprobleme verursacht hätte.

Deshalb halte ich das auch für eine Fehlentscheidung, schlechte Programmierung zu unterstützen und guten Code nicht zu ermöglichen...
Ich denkek das Embaracadero diese Entscheidung nicht so getroffen hätte wenn nicht durch C/C++/C#/Java/... dieser Weg nicht schon vorgezeichnet wäre. Wieso hier einen eigenen Weg gehen der Eigentlich nur zu Problemen bei der interoperabilität führt. Eine "reine" Entscheidung hätte dazu geführt das jeder der was mit einem Delphi-programm zu tun hat wissen muss das int von C/C++/C#/Java/... unter Delphi int32 bedeutet. Jeder würde den integer vorschlagen und müsste erstmal die Probleme bei 64-Bit-Zusammenspiel debuggen.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:42 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf