Wolfgang Ehrhardts CRC/Hash Routinen - kompilieren schlägt fehl - IDE-Bug?

[a.def]

Ich bin heute auf Wolfgang Ehrhardts CRC- und Hash-Routinen gestoßen. Die sollen wohl wahnsinnig schnell sein, weswegen ich mich dafür interessiere.

Ich habe aber ein seltsames Problem, wenn ich mir die Units die ich brauche ins Projekt hinzufüge und kompilieren möchte.
Der Compiler meckert, dass der Bezeichner THashContext nicht deklariert sei. Wenn ich aber STRG+Linkklick drauf mache, lande ich in der Unit Hash.pas.

Wieso findet der Compiler die Unit nicht?

Ein Beispielprojekt mit allen benötigten Units befindet sich im Anhang. Bekommt ihr das Projekt kompiliert?

Link zu Wolfgang Ehrhardts Units: http://www.wolfgang-ehrhardt.de/crchash_de.html

[gammatester]

Zitat:

Zitat von a.def (Beitrag 1370427)

Ich bin heute auf Wolfgang Ehrhardts CRC- und Hash-Routinen gestoßen. Die sollen wohl wahnsinnig schnell sein, weswegen ich mich dafür interessiere.

Wieso findet der Compiler die Unit nicht?

Ein Beispielprojekt mit allen benötigten Units befindet sich im Anhang. Bekommt ihr das Projekt kompiliert?

Link zu Wolfgang Ehrhardts Units: http://www.wolfgang-ehrhardt.de/crchash_de.html

Das Problem liegt darin, daß Delphi ab XE8 eine eigene Hash-Unit hat, und durch nichts zu überzeugen ist, daß es die Unit im Arbeitsverzeichnis oder entsprechend der Uses-Liste verwendet soll. Ist bekannt, siehe hier http://www.delphipraxis.net/190245-u...nd-hash-2.html und http://www.delphipraxis.net/184810-x...stem-hash.html. Aber selbst dann kann man deinen Code nicht übersetzen (zB mit D18) weil er einige Fehler hat. Eine korrigierte Funktion sieht so aus

Delphi-Quellcode:

function SHA1Text(const s: string): string;
var
 Context: THashContext;
 SHA256Digest: Hash.TSHA256Digest;
begin
 SHA256.SHA256Init(Context);
 SHA256.SHA256Update(Context, pChar(s), length(s));
 SHA256.SHA256Final(Context, SHA256Digest);
 Result := Mem_Util.HexStr(@SHA256Digest, SizeOf(SHA256Digest));
end;

und sollte dann sinnvollerweise SHA256Text heißen. Ich kann selbst dann nicht übersetzen, weil die res-Datei fehlt.

Gruß Gammatester

[a.def]

Heißt das also die einzige Lösung besteht darin, dass ich die Unit Hash von Wolfgang E. umbenennen muss?

Zitat:

Aber selbst dann kann man deinen Code nicht übersetzen (zB mit D18) weil er einige Fehler hat. Eine korrigierte Funktion sieht so aus

Das waren leider noch Code-Leichen. Im neuen Archive oben sind die raus.

Zitat:

Ich kann selbst dann nicht übersetzen, weil die res-Datei fehlt.

Die ist doch gar nicht zwingend erforderlich oder?
Ich kann die aus meinem Projektverzeichnis löschen und nicht kompilieren (siehe Fehler erster Post). Aber auch wenn sie vorhanden ist kann ich nicht kompilieren.

[idefix2]

Zitat:

Zitat von a.def (Beitrag 1370438)

Ich kann die aus meinem Projektverzeichnis löschen und nicht kompilieren (siehe Fehler erster Post). Aber auch wenn sie vorhanden ist kann ich nicht kompilieren.

Naja, zum Nicht-kompilieren ist sie sicher nicht erforderlich :)

[a.def]

Wenn ich hash.pas in W.E.Hash.pas umbenenne, komme ich bereits weiter.
Wo man dann aber stecken bleibt ist in Mem_Util.Base64DecStr in Block

Delphi-Quellcode:

function Base64DecStr({$IFDEF CONST}const {$ENDIF} es: BString): BString;
var
 {$IFNDEF RESULT}
 result: BString;
 {$ENDIF}
...

// Funktioniert mit XE2 problemlos. Ab XE8 nicht mehr.

Wenn man das auskommentiert (ebenfalls in anderen Funktionen wo es diese Re-Deklaration gibt) kommt man weiter und es kompiliert.
Result: BString ist hier meiner laienhaftung Meinung doch gar nicht notwendig, da der Funktionsrückgabewert doch eh schon BString ist.


Resultat dieses kleinen Ausritts ist dann ein SHA256-Hash, der nicht mit dem übereinstimmt was andere Hasher sagen.
Es gibt vermutlich also noch weitere Probleme nur fraglich wo.

Wenn ich diese Library zum problemlosen Funktionieren bekomme, wird es definitiv meine erste Wahl vor allen anderen :thumb:

[gammatester]

Zitat:

Zitat von a.def (Beitrag 1370440)

Wenn ich hash.pas in W.E.Hash.pas umbenenne, komme ich bereits weiter.
Wo man dann aber stecken bleibt ist in Mem_Util.Base64DecStr in Block

Delphi-Quellcode:

function Base64DecStr({$IFDEF CONST}const {$ENDIF} es: BString): BString;
var
 {$IFNDEF RESULT}
 result: BString;
 {$ENDIF}
...

// Funktioniert mit XE2 problemlos. Ab XE8 nicht mehr.

Wenn man das auskommentiert (ebenfalls in anderen Funktionen wo es diese Re-Deklaration gibt) kommt man weiter und es kompiliert.
Result: BString ist hier meiner laienhaftung Meinung doch gar nicht notwendig, da der Funktionsrückgabewert doch eh schon BString ist.

Wenn man was auskommentiert? Und welche Re-Deklaration? BString ist ein String[255], also kein String (bei die wohl bei dir ein Unicode-String ist). Außerdem ist er statisch und nicht dynamisch (Strings in XE8 sind dynamisch).

Wenn du dynamische Strings brauchst, sieh mal in Unit base2n.pas für ansistrings.

[a.def]

Wenn man folgendes auskommentiert

Delphi-Quellcode:

 {$IFNDEF RESULT}
 result: BString;
 {$ENDIF}

Weil der Funktionsrückgabewert ist ja eh schon BString

Delphi-Quellcode:

function Base64DecStr({$IFDEF CONST}const {$ENDIF} es: BString): BString;

Nur dann funktioniert es. Aktuell versuche ich mit Tokyo Starter zu kompilieren.

[gammatester]

Zitat:

Zitat von a.def (Beitrag 1370443)

Wenn man folgendes auskommentiert

Delphi-Quellcode:

 {$IFNDEF RESULT}
 result: BString;
 {$ENDIF}

Weil der Funktionsrückgabewert ist ja eh schon BString

Delphi-Quellcode:

function Base64DecStr({$IFDEF CONST}const {$ENDIF} es: BString): BString;

Nur dann funktioniert es. Aktuell versuche ich mit Tokyo Starter zu kompilieren.

Wenn Du das auskommentieren mußt, stimmt noch mehr nicht. Für Delphi sollte RESULT immer definiert sein: std.inc Zeile 494. (Hinweis: es gibt Pascal-Versionen die kein result für's Funktionsergebnis kennen!)

[a.def]

Wie gesagt. Ich teste es mit XE8 Pro und Tokyo Starter und es tritt bei beiden auf.
Tritt nur bei Tokyo auf. Der Hash ist bei XE8 aber trotzdem nicht korrekt.

[gammatester]

Zitat:

Zitat von a.def (Beitrag 1370445)

Wie gesagt. Ich teste es mit XE8 Pro und Tokyo Starter und es tritt bei beiden auf.
Tritt nur bei Tokyo auf. Der Hash ist bei XE8 aber trotzdem nicht korrekt.

Für Tokyo solltest Du die neueste http://www.wolfgang-ehrhardt.de/std.zip verwenden. Deine ist über ein Jahr alt, da gab es Tokyo noch nicht.

PS: Warum hast du eigentlich so viele Änderungen am Code vorgenommen (zB 124 bei sha256)?