Char Array mit mehreren Nulls

  • C/C++

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Char Array mit mehreren Nulls

    Mit meinen beschiedenen C Kenntnissen versuche ich gerade eine DLL zur Kompression von Strings zu schmieden.
    Dies geht auch ganz gut, mit zlib für die Komprimierung habe ich bereits die ersten Tests abgeschlossen, alles geht wie es soll.

    Jetzt habe ich bloß ein kleines Problem, wo es darum geht eine DLL drauß zu machen, die auch mit dem GM kompatibel ist.
    Nach der Komprimierung eines char Arrays lässt sich das Ergebnis nur als byte Array halten, da dieser auch 0en enthält. Da die Schnittstelle zwischen GM und DLLs nur char Arrays akzeptiert, müsste ich den byte Array casten. Dies gestaltet sich als Problem, da in einem char Array die erste 0, also "\0" als ende, als null-terminator, interpretiert.

    Ich habe keinen Ansatz, wie ich das zu Handhaben sollte. Zlib bietet keinerlei Einstellungsmöglichkeiten. Ein Gedanke den ich kurz verfolgt hatte war es, die "\0" mit irgendwas anderem, eindeutigem zu ersetzten, wie zb. drei @@@ Zeichen. Dies könnte meistens funktionieren, ist aber wohl nicht ganz Sinn der Sache - mir gefällt die Lösung einfach nicht.

    Falls jemand was zu gucken haben will, hier die compress Funktion.

    Andere weitere Möglichkeit, die ich ganz bestimmt nicht toll finde, ist es, das komprimierte Ergebnis in eine temporäre Datei zu schreiben, und dann nur den Pfad zu übergeben. Der GM könnte diese Datei dann wieder einlesen. Toll finde ich das aus dem Grund nicht, dass es ein vielfaches langsamer ist, als es direkt zu übergeben.

    Ich benutze die zlib1.dll, die ich mir selber compiliert habe. Kann also folglich selber dort etwas ändern. So wie ich es allerdings sehe, führt das Probklem ganz auf den Kern zurück, auf den LZ77 algo zurück.


    Hoffe auf Hilfe

    MfG SDX
  • Ich würde einen String, der auch null-bytes enthalten kann, einfach durch mehrere Funktionsaufrufe übergeben, wobei jeweils der Teilstring bis zum nächsten null-byte übergeben wird. Also beim ersten Funktionsaufruf wird der String vom Anfang bis zum ersten null-byte zurückgegeben. Dann weiß der GM, das er ein null-byte anhängen muss. Danach wird beim nächsten Funktionsaufruf der Teil zwischen dem ersten und zweiten null-byte zurückgegeben und vom GM angehängt usw.

    Man könnte natürlich den String auch erst, wie du schon erwähnt hast, in der DLL kodieren, an den GM übergeben und ihn anschließend im GM wieder dekodieren. Allerdings würde das Dekodieren, da es im GM stattfindet, wohl länger dauern als obige Methode. Wobei die Methode oben wohl umso langsamer wird, je mehr null-bytes enthalten sind. Falls du es mit dem Kodieren versuchen willst, musst du es natürlich eineindeutig machen. Also das null-byte durch @@@ zu kodieren wird natürlich alleine nicht ausreichen. Eine mögliche Kodierung wäre: 0 wird zur Folge (1, 1) und 1 wird zur Folge (1, 2) und der Rest bleibt wie er ist.

    Beispiel:

    Zu kodierende Folge an Bytes: 37, 238, 101, 0, 45, 1, 1, 78

    Kodierte Folge: 37, 238, 101, 1, 1, 45, 1, 2, 1, 2, 78
  • Die zweit genannte Idee hat allerdings den Hacken, dass die Folge (1,2) dann sowohl (1) als auch (1,2) bedeuten kann.
    Die erstgenannte ist an und für sich schon ganz gut. Boxxar nannte mir soeben auch die Möglichkeit, es als base64 zu übergeben.

    Ein check auf GMs Seite zeigte, dass dort Null keinen großen Effekt haben. Die einzigen Funktionen, die auf null terminatoren zu achten scheinen, sind die draw_text funktionen, real() sowie string_replace_all(). Allesamt welche, die man mit komprimierten strings nicht braucht.

    Ich habe jetzt 3 Möglichkeiten, die ich mal genauer unter die Lupe nehmen werde: in Portionen senden, über externe Wege (Dateien) und base64 - wobei ich die erstgenannte schon für die sauberste halte.

    MfG SDX
  • SDX schrieb:

    Die zweit genannte Idee hat allerdings den Hacken, dass die Folge (1,2) dann sowohl (1) als auch (1,2) bedeuten kann.

    Nein, die 1 wird ja zu (1, 2). D.h. wenn in der kodierten Folge eine einzelne 1 steht, dann bestimmt einfach das darauf folgende Zeichen ob es eine 0 oder 1 wird. Die Folge (1, 2) wird ja durch die Kodierung zu (1, 2, 2). Dass die Kodierung so funktioniert, liegt übrigens an der Präfixfreiheit, wie sie beispielsweise auch bei der Huffman-Kodierung anzutreffen ist.

    SDX schrieb:

    Boxxar nannte mir soeben auch die Möglichkeit, es als base64 zu übergeben.

    Das ist natürlich auch eine Möglichkeit. Ich glaube, wie man es am Ende kodiert, ist relativ egal. Von der Performance her sollten sich die Methoden alle nicht viel nehmen.
  • Benutzer online 1

    1 Besucher

  • Tags