![]() |
AW: Float Zahlen in Hex Zahlen umwandeln
Zitat:
|
AW: Float Zahlen in Hex Zahlen umwandeln
Zitat:
Eine Hexadezimalzahl ist eine "Zahl" in Hexadezimaler Darstellung. (0-15 pro Ziffer) Einen Integer kann mal man auch in vielen Zahlensystemen darstellen (meisten kennen wir aber das Dezimalsystem mit 0-9 pro Ziffer) oder Binär mit 0-1 pro Ziffer. Als ganze Zahl läßt sich aber das Zahlensystem leicht umrechnen, weswegen es auch eine passende Funktion gibt. Wenn man aber den "binären" Speicherhinhalt des "Float" betrachtet, dann ist der auch Hexadezimal darstellbar, aber der enthaltene Fießkommawert ist es nicht, weswegen es auch keine funktion dafür gibt. Für den binären Inhalt des speichers gibt es z.B. ![]() Aber wie schon erwähnt wurde, muß man da wissen in welcher Reihenfolge die Bytes übertragen werden müssen. IntToHex stellt die Bytes z.B. in einer anderen Reihenfolge dar, wie das BinToHex. BinToHex: kleines Byte im speicher = links und kleines Byte im Hex-String ist auch links IntToHex: großes Byte im Hex ist links (also kleines Byte ist rechts) |
AW: Float Zahlen in Hex Zahlen umwandeln
Zitat:
(Und welcher Anfänger und wieviele Fortgeschrittene haben noch nie etwas von LittleEndian und BigEndian gehört?) Gruß K-H |
AW: Float Zahlen in Hex Zahlen umwandeln
@gammatester
Nun ja, da werden sich die Geister wohl ewig scheiden und das ist ja auch nicht schlimm ;-). Typecast: tatsächlich ist es so, dass ich bereits aus Programmen Typecasts herausgenommen habe, indem ich einmal den Typ bestimmt und anschließend einer Variable zugewiesen habe. Dadurch habe ich Sekunden(!) gewonnen. So ganz ohne Rechenaufwand kann das also nicht stattfinden. Diskutieren kann man allerdings darüber, ob ein Cast auf ein "array of byte" verglichen mit einem Cast auf eine Klasse tatsächlich vergleichbar sind. Ob mein "Konstrukt" weniger durchsichtig ist, kann ich nicht beurteilen. Einfacher, performanter und flexibler ist es auf jeden Fall, denn: Das Record nimmt genau 4 Byte im Speicher ein. Nicht mehr und nicht weniger. Durch Definition des Records gibt es keine Typumwandlung im eigentlichen Sinne. Im Grunde teilen sich 11 Variablen verschiedenen Typs den selben Speicherbereich. Nämlich genau die vom Record belegten 4 byte. FloatValue, IntValue und CardinalValue dabei die kompletten 4 byte. Die Variablen ByteHH, ByteHL, ByteLH, ByteLL von links nach rechts ebenfalls. Das selbe gilt für die Variante mit den 4 Charactern. (H steht für High, L für Low) Für die Umwandlung von Single in Integer sind demnach genau(!) ein Schreib + Ein Lesezyklus notwendig. Belibige Bytekonvertierungen sind ebenfalls problemlos ohne Aufwand möglich. Ich weiß nicht was du mehr willst? |
AW: Float Zahlen in Hex Zahlen umwandeln
Aber Hallo,
gibt's jetzt wieder Glaubenskriege? Meiner Unmaßgeblichen Meinung nach ist es egal ob ich mit einem varianten Record oder mehreren Typen arbeite. Solange ich die Daten nicht extra noch einmal schreiben muß, was bei 4 Byte ja nun auch nicht soo viel ist, ist es eigentlich nur Geschmackssache. Wobei ich zugeben muß, daß variante Records sich u.U. nicht so einfach erschließen. (übrigens
Delphi-Quellcode:
ist irgendwie untergegangen!?)
absolute
Was ich bezweifle, ist, daß Typecasts Zeit kosten, da es sich ja eigentlich um eine andere Interpretation vorhandener Daten handelt. Wäre schon schön, wenn das jemand mit einem Beispiel belegen könnte. Gruß K-H |
AW: Float Zahlen in Hex Zahlen umwandeln
Zitat:
Mit ein paar Ausnahmen. - implizite/explizite "TypCasts" über Record-Operatoren - gewisse TypCast von z.B. Strings, wo Delphi ein bissl CompilerMagic drin versteckt und z.B. Konvertierungen der String und/oder CodePages vornimmt |
AW: Float Zahlen in Hex Zahlen umwandeln
Zitat:
Bei Casts auf einen nicht-Klassen-Typ erfolgt keine Überprüfung. Allerdings entspricht die Record-Methode weit eher der Typsicherheit, die ich an der Uni mal mit dem Ur-Pascal aufgenommen habe ;-) |
AW: Float Zahlen in Hex Zahlen umwandeln
Records mit varianten Teilen entspricht quasi dem Absolute.
Nur daß beim Absolute keinerlei Prüfungen vom Compiler vorgenommen werden. (beim Record werden gemanagete Typen "verboten") Ob man nun den Record nimmer und die Daten erst reinkopiert, um sie dann "gecastet" da auszulesen oder ob man den Typ direkt zum Casten nimmt, ist geschmackssache, wobei der direkte Weg sich die zusätzliche Kopieroperation erspart. Man kann sich auch gern eine generische Funktion schreiben, welche die eine Variable als Parameter annimmt und das im anderen Format ausgibt. Entspricht dann einem "expliziten" Cast, welchen man sich via Record-Operatoren basteln kann. Und dann gibt es noch den Weg über einen Record-Helper, wo man sich eine Konvertierungsfunktion basteln kann, wie z.B. das .ToString an Klassen und neuerdings auch an einigen generischen Typen wie z.B. den Integern. Oder man geht den klassischen Weg und nutzt eine Konvertierungsprozedur mit In-Param und Out/Var-Param, oder das Out als Result. |
AW: Float Zahlen in Hex Zahlen umwandeln
Hättest du vielleicht mal ein Beispiel oder einen Link zu der Absolute Methode?
Diese direktive kenne ich überhaupt nicht und wird in der Delphi- Hilfe von XE2 auch nur in einer Tabelle als direktive erwähnt aber mit keinem Wort erklärt. Eine Möglichkeit gäbe es zur eigentlichen Aufgabe aber nocht. Aus Faulheit hätte ich diese sicher auch gewählt ;-)
Code:
var SingleVar : Single; Intvar : integer; begin SingleVar := 1.1234; move(SingleVar, IntVar, 4); showmessage(IntToHex(IntVar)); end; |
AW: Float Zahlen in Hex Zahlen umwandeln
Delphi-Quellcode:
Es besagt einfach nur, daß diese Variable an der selben "absoluten" Adresse beginnen soll, wie die angegebene andere Variable.
var
SingleVar: Single; IntVar: Integer absolute SingleVar; begin SingleVar := 1.1234; ShowMessage(IntToHex(IntVar)); end; Aber ein Cast ist da eh besser/einfacher, vorallem da der Compiler einem bescheid gibt, wenn der Cast nicht "möglich" ist, z.B. aufgrund der Typen oder Speichergröße.
Delphi-Quellcode:
var
SingleVar: Single; begin SingleVar := 1.1234; ShowMessage(IntToHex(Integer(SingleVar))); end; |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:19 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-2025 by Thomas Breitkreuz