3. Portabilität von Boost.Hash

Portabilität von Boost.Hash

  • N

    Hallo zusammen

    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.

    0
  • C

    Fast-Fix wäre wohl einfach eine 64bit .exe auf Windows zu erstellen. Welchen Compiler benutzt du? Mit VS 2012 sollte das kein Problem sein. Ansonsten halte ich das aber eh für keine gute Idee - wer garantiert dir denn, dass diese Hash Funktion immer gleich bleibt? Ich glaube nicht, dass das dazu gedacht ist, Daten abzuspeichern.

    0
  • N

    Ja, Boost.Hash kann ich wohl nicht verwenden.

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

    0
  • T

    Falls Du die Daten (inkl. Hash) mit Boost.Serialization in die Files serialisierst, schafft ev. die folgende Header-Only Library abhilfe: http://epa.codeplex.com/

    Simon

    0
  • N

    Momentan verwende ich nicht Boost.Serialization. Die Bibliothek werde ich mir aber merken, könnte sich mal nützlich erweisen. Danke, theta!

    0
  • T

    Nexus schrieb:

    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

    0
  • N

    TyRoXx schrieb:

    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.

    0
  • K

    Das ist etwas, worueber ich mir auch den Kopf zerbrochen hab. Gibt wohl keine schoene Loesung dafuer.

    0
Anmelden zum Antworten