hex wert subtrahieren

[nimmy]

hallo zusammen,

ich möchte den einen hex wert ($04000000) vom anderen ($07FFFFFF) subtrahieren. den neuen wert lasse ich mir zur probe ausgeben:

Delphi-Quellcode:

log('range total: ' + '$' + (Format('%.8x',[strtoint64('$' + inttohex(((StrToInt64('$07FFFFFF') - StrToInt64('$04000000')) div 2), 8))])));

die ausgabe im memofeld erstaunt mich:
$01FFFFFF

während calc.exe es richtig macht:
$03FFFFFF

inttohex sieht so aus:

Delphi-Quellcode:

function StrToHex(S:string): string;
var
  i: byte; //Attention: max 255 characters, should be enough
begin
  Result:= '';
  for i := 1 to length (S) do
    Result := Result + IntToHex(ord(S[i]), 2);
end;

ich blicks nicht, was mache ich falsch? für jede hilfe bin ich dankbar.

beste grüße,

thomas

[himitsu]

Ich blick's auch nicht.

Hab mir das angesehn und dein Code rechnet korrekt.
01FFFFFF ist vollkommen richtig, wenn man sich ansieht, was du da rechnest.

> DIV 2


Und wozu die doppelte Konvertierung?
Nach der Berechnung IntToHex, zurück mit StrToInt64 und dann nochmal das Selbe via Format.

Zitat:

inttohex sieht so aus:

Ja?

Außerdem zeigst du da StrToHex
und Dieses wurde in obrigem Code nichtmal verwendet.

IntToHex

Zitat:

//Attention: max 255 characters, should be enough

Man könnte natürlich auch einen Integer verwenden. :roll:


Und es wundert mich ganz besonders, daß in der gezeigten Funktion so viele Großbuchstaben vorhanden sind.

[nimmy]

ahja ist ja schon spät. inttohex ist delphi intern. der entscheidende hinweis ist das Div 2, hmm ein übrigbleibsel von was auch immer. danke! habe ich andauernd überlesen. weshalb du integer verwendest, wenn du mit maximal 255 zeichen auskommst, erschließt sich mir jedoch nicht. nichtsdestotrotz! bin happy, gute nacht. :o)

[Buddelfish]

Sag mal, findest Du deinen Code nicht fürchterlich unleserlich?

Delphi-Quellcode:

v1 := StrToInt64('$07FFFFFF');
v2 := StrToInt64('$04000000');
v3 := (v1 - v2) div 2;
log('range total: ' + '$' + (Format('%.8x',[strtoint64('$' + inttohex(v3, 8))])));

Aber wieso konvertierst Du eigentlich von int nach hex und dann wieder von hex nach int? Na wirst schon deine Gründe haben.

[nimmy]

eh, wieso jetz wieder div 2?

[himitsu]

Er hatt den Code von da oben einfach "nur" zerlegt. :zwinker:

Wobei da immernoch die doppelte Konvertierung drin steckt, obwohl ja Eine (der beispielhaft 6 da unten Stehenden) reicht.

Delphi-Quellcode:

v1 := StrToInt64('$07FFFFFF');
v2 := StrToInt64('$04000000');
v3 := v1 - v2;  //v3 := (v1 - v2) div 2;
log(Format('range total: $%.8x', [v3])));

v1 := StrToInt64('$07FFFFFF');
v2 := StrToInt64('$04000000');
log(Format('range total: $%.8x', [v1 - v2])));

log(Format('range total: $%.8x', [StrToInt64('$07FFFFFF') - StrToInt64('$04000000')])));

// oder

v1 := StrToInt64('$07FFFFFF');
v2 := StrToInt64('$04000000');
v3 := v1 - v2;  //v3 := (v1 - v2) div 2;
log('range total: $' + IntToHex(v3, 8));

v1 := StrToInt64('$07FFFFFF');
v2 := StrToInt64('$04000000');
log('range total: $' + IntToHex(v1 - v2, 8));

log('range total: $' + IntToHex(StrToInt64('$07FFFFFF') - StrToInt64('$04000000'), 8));

// gegenüber

log('range total: ' + '$' + (Format('%.8x',[strtoint64('$' + inttohex(((StrToInt64('$07FFFFFF') - StrToInt64('$04000000')) div 2), 8))])));

Nutzlose Klammern und unnötige Befehle können auch die Lesbarkeit behindern.
Bei den aufgeteilten Varianten wäre das

Delphi-Quellcode:

div 2

bestimmt ganz schnell aufgefallen. :zwinker:

PS: Das CamelCase diehnt der Lesbarkeit und die sollte Im Code tunlichst nicht verloren gehen. [StrToInt64]
Nur zur Info: Das underscore-separated, z.B. aus der WinAPI, hat den selben Grundgedanken. [str_to_int_64 / STR_TO_INT_64]

[Medium]

Er hat einfach deinen Code von oben umgeschrieben, so wie er war. Es ist auch eher als Beispiel zu lesen, das zeigen soll, dass ein paar Zwischenschritte Lesbarkeit und Nachvollziehbarkeit fast unendlich verbessern ;)

Edit: Hach, Tabs im Voraus öffnen und dann ohne Refresh antworten führt öfters zu einem schnellen Himi mit passender Antwort :D

[Medium]

Es wäre gf. noch hinzuzufügen, dass Delphi Zahlenliterale direkt im Hex-Format verarbeiten kann, dafür sind die Strings nicht nötig:

Delphi-Quellcode:

v1 := $07FFFFFF;
v2 := $04000000;
v3 := v1 - v2;  //v3 := (v1 - v2) div 2;
[...]

[nimmy]

danke für eure antworten, der code sieht nun sauberer aus und funktioniert. was den begriff CamelCase angeht, klingt interessant, macht ja auch sinn. beim einrücken achte ich zb penibel auf abstände. um die formatierung habe ich mich bisher kaum gekümmert, mal beachte ich groß-kleinschreibung, mal nicht, mal baue ich unterstriche ein und manchmal CamelCase ich auch.
aber wir kommen vom thema ab :).

gn8

[himitsu]

Sei froh, daß Delphi so nett ist.

z.B. im .Net ist das Alles gerne auch mal CaseSensitiv, womit man da wirkich prenibel drauf achten muß. (oder man lässt sich das von der Codevervollständigung beim Schreiben gleich alles anpassen)

[Furtbichler]

Zitat:

Zitat von himitsu (Beitrag 1249787)

Sei froh, daß Delphi so nett ist ... z.B. im .Net ist das Alles gerne auch mal CaseSensitiv

Hat mich anfangs genervt, aber mittlerweile finde ich es fürchterlich, Case*in*sensitiv zu programmieren. Endlich kann man auf die dämlichen Präfixe ('f' für Felder, 'a' für Parameter, 'E' für Exceptions etc.) verzichten. Man gewöhnt sich sehr schnell daran und die Codevervollständigung hilft wirklich ungemein.

[Sir Rufo]

Zitat:

Zitat von Furtbichler (Beitrag 1249794)

Zitat:

Zitat von himitsu (Beitrag 1249787)

Sei froh, daß Delphi so nett ist ... z.B. im .Net ist das Alles gerne auch mal CaseSensitiv

Hat mich anfangs genervt, aber mittlerweile finde ich es fürchterlich, Case*in*sensitiv zu programmieren. Endlich kann man auf die dämlichen Präfixe ('f' für Felder, 'a' für Parameter, 'E' für Exceptions etc.) verzichten. Man gewöhnt sich sehr schnell daran und die Codevervollständigung hilft wirklich ungemein.

Ist aber wohl mehr philosophisch zu sehen und ob man sich daran gewöhnen kann, vor allem wenn die Gewohnheit eine andere bis dato war.

Das es geht - die Umgewöhnung - bestätigst du ja gerade ;)

[Namenloser]

Zitat:

Zitat von Furtbichler (Beitrag 1249794)

Zitat:

Zitat von himitsu (Beitrag 1249787)

Sei froh, daß Delphi so nett ist ... z.B. im .Net ist das Alles gerne auch mal CaseSensitiv

Hat mich anfangs genervt, aber mittlerweile finde ich es fürchterlich, Case*in*sensitiv zu programmieren. Endlich kann man auf die dämlichen Präfixe ('f' für Felder, 'a' für Parameter, 'E' für Exceptions etc.) verzichten. Man gewöhnt sich sehr schnell daran und die Codevervollständigung hilft wirklich ungemein.

Wie machst du das denn? Normalerweise verwendet man einen kleinen Anfangsbuchstaben für Variablen und einen großen Anfangsbuchstaben für Klassen. Wie unterscheidest du jetzt Felder von Parametern und lokalen Variablen, und Exceptions von anderen Klassen?

[Mikkey]

Zitat:

Zitat von Namenloser (Beitrag 1249811)

Zitat:

Zitat von Furtbichler (Beitrag 1249794)

Zitat:

Zitat von himitsu (Beitrag 1249787)

Sei froh, daß Delphi so nett ist ... z.B. im .Net ist das Alles gerne auch mal CaseSensitiv

Hat mich anfangs genervt, aber mittlerweile finde ich es fürchterlich, Case*in*sensitiv zu programmieren. Endlich kann man auf die dämlichen Präfixe ('f' für Felder, 'a' für Parameter, 'E' für Exceptions etc.) verzichten. Man gewöhnt sich sehr schnell daran und die Codevervollständigung hilft wirklich ungemein.

Wie machst du das denn? Normalerweise verwendet man einen kleinen Anfangsbuchstaben für Variablen und einen großen Anfangsbuchstaben für Klassen. Wie unterscheidest du jetzt Felder von Parametern und lokalen Variablen, und Exceptions von anderen Klassen?

Für C# gibt es Quellcoderichtlinien. Nach denen verwendet man für Objektvariablen kleine Anfangsbuchstaben, für Klassen, Interfaces, Methoden und Properties große. Wir hatten es uns damals angewöhnt (weil der "m_"-Prefix verpönt ist) Zugriffe auf eigene Klassenmember mit "this.~" zu kennzeichnen (geht in Delphi per "self.~" auch). Solange Methoden in ihrer Länge im Rahmen bleiben, ist eine Unterscheidung zwischen Parametern und lokalen Variablen nicht erforderlich.

Daneben wählt man halt die Namen von Methoden so, dass sie mit einem Verb beginnen, so entfällt auch die Verwechslungsgefahr mit Klassen und Properties.