Ich verwende Boost.Functional/Hash in einem Projekt, das ich momentan von Windows auf Linux portiere. Dabei schreibe ich Hash-Werte in Dateien. Ich würde gerne Dateien auf Linux lesen können, die auf Windows geschrieben wurden.

Leider verwenden alle Hash-Funktionen von Boost size_t , was auf Windows 32 und auf Linux 64 Bit gross ist. Das finde ich eine ziemlich dumme Einschränkung, warum wurde hier size_t gewählt? Weil die Werte in Hash-Maps zur Indizierung verwendet werden? Ich bin sowieso kein Fan von intransparenten Typedefs wie size_t . Dauernd muss man casten, wenn man eine einheitliche Schnittstelle haben will...

Was bieten sich für Alternativen zur Hash-Berechnung an? Selbst schreiben? Boost-Code anpassen? Noch eine Bibliothek möchte ich eher nicht nehmen, es sei denn sie ist leichtgewichtig und header-only.

Da ich das ganze für einfache Checksummen benötige (nichts Kryptographisches), würde wahrscheinlich sogar sowas wie Adler-32 ausreichen...

Simon

Leider verwenden alle Hash-Funktionen von Boost size_t , was auf Windows 32 und auf Linux 64 Bit gross ist. Das finde ich eine ziemlich dumme Einschränkung, warum wurde hier size_t gewählt? Weil die Werte in Hash-Maps zur Indizierung verwendet werden?

Wofür denn sonst? Der Hash-Wert hat genau den Typ, den man auf der Plattform braucht.

Nexus schrieb:

Ich bin sowieso kein Fan von intransparenten Typedefs wie size_t . Dauernd muss man casten, wenn man eine einheitliche Schnittstelle haben will...

size_t gibt es, damit man einheitliche Schnittstellen hat.
Dass du das Typsystem nicht verstanden hast, ist nicht die Schuld von C++ oder Boost.

Nexus schrieb:

Was bieten sich für Alternativen zur Hash-Berechnung an? Selbst schreiben? Boost-Code anpassen? Noch eine Bibliothek möchte ich eher nicht nehmen, es sei denn sie ist leichtgewichtig und header-only.

Boost.CRC

Wofür denn sonst?

Schon mal dran gedacht, dass man Hashes auch ausserhalb von Hash-Maps verwenden kann? Aus irgendeinem Grund bietet Boost die Funktionalität wohl separat an.

TyRoXx schrieb:

size_t gibt es, damit man einheitliche Schnittstellen hat.
Dass du das Typsystem nicht verstanden hast, ist nicht die Schuld von C++ oder Boost.

Einheitlichkeit war die ursprüngliche Absicht von size_t , momentan siehts leider nicht immer so rosig aus. Für viele Fälle, wo man die Generizität nicht braucht, zahlt man einen hohen Preis. Das fängt bei std::size_t vs. size_t an. Beispiele für inkonsistente Schnittstellen, wo es jeweils um eine Anzahl Elemente geht:

• std::count() gibt std::ptrdiff_t zurück.
• std::map::count() gibt std::size_t zurück.
• std::vector::size() gibt std::size_t zurück.
• std::istream::read() nimmt std::streamsize , obwohl das Ziel ein std::vector<char> sein kann. ( streamsize ist signed, aber der einzige Ort wo negative Werte verwendet werden, ist die deprecated std::strstream -Klasse).

Dabei ist ausser Acht gelassen, dass die eigentlichen Rückgabetypen von den Iteratoren/Allokatoren abhängen. In ganz generischem Code müsste man also die Typedefs difference_type und size_type verwenden. Wenn man in eigenem Code Typen mit fester Grösse wie std::uint32_t braucht, muss man erneut casten.

Aber das liegt wohl alles daran, dass ich das C++-Typsystem nicht verstanden habe

TyRoXx schrieb:

Boost.CRC

Okay, danke für den Hinweis.