Katie: ICO mit C++ verarbeiten

Hallo,

ich arbeite zurzeit an einer Art Serveranwendung. Diese Serveranwendung muss auch *.ico, *.png, und *.jpg verarbeiten. Nun ist mir aber aufgefallen das in diesen Dateien die ASCII Null nicht dieselbe Bedeutung hat wie in einer *.txt Datei. Da sind ganz vielen Nullen auch schon ganz am Anfang. Wenn in einem char* String eine Null auftaucht wird der String als zu Ende erklärt. Was aber falsch ist da die Datei 150 KB hat.

Wie behandelt man solche Dateien? Wo und Wie speichert man sie ab?
Das stellt mich vor eine echte Herausforderung. Ich hoffe ich kann sie mit eurer Hilfe meistern.

Katie

  1. Hallo,

    ich arbeite zurzeit an einer Art Serveranwendung. Diese Serveranwendung muss auch *.ico, *.png, und *.jpg verarbeiten. Nun ist mir aber aufgefallen das in diesen Dateien die ASCII Null nicht dieselbe Bedeutung hat wie in einer *.txt Datei. Da sind ganz vielen Nullen auch schon ganz am Anfang. Wenn in einem char* String eine Null auftaucht wird der String als zu Ende erklärt. Was aber falsch ist da die Datei 150 KB hat.

    Wie behandelt man solche Dateien? Wo und Wie speichert man sie ab?

    Nunja, dass ein 0-Byte einen String beendet, ist aber auch eine C/C++-Eigenheit, in anderen Programmiersprachen ist das nicht unbedingt der Fall.

    Wenn Du nun Binärdaten in C/C++ verarbeitest, dann bleibt Dir nichts anderes übrig, als Dir zu merken, wie groß die Binärdaten überhaupt waren. Sprich: Sobald Du einen Block einliest, merkst Du Dir, wie groß dieser Block war, dann ist es auch egal, wie viele 0-Bytes in dem Block vorkamen, Du kennst die Blockgrenze immer an Hand der Größe des Blocks.

    Viele Grüße,
    Christian

    1. Also jetzt ein wenig verspätet meine Antwort, aber ...

      Also herzlichen Danke für diese Antwort.

      Ich habe das genauso umgesetzt und funktioniert. Zusätzlich konnte ich einen Geschwindigkeitsvorteil von 9,35% im Durchschnitt feststellen.

      Danke.

      Katie

      1. Hi,

        Ich habe das genauso umgesetzt und funktioniert. Zusätzlich konnte ich einen Geschwindigkeitsvorteil von 9,35% im Durchschnitt feststellen.

        Einen Geschwindigkeitsunterschied zwischen was? Soetwas kann man feststellen wenn es um Optimierung, nicht um Fehlerbeseitigung geht..

        Gruß,
        Felix

        --
        Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jedermann ist überzeugt, dass er genug davon habe.
        René Descartes
        1. Ich habe das genauso umgesetzt und funktioniert. Zusätzlich konnte ich einen Geschwindigkeitsvorteil von 9,35% im Durchschnitt feststellen.
          Einen Geschwindigkeitsunterschied zwischen was? Soetwas kann man feststellen wenn es um Optimierung, nicht um Fehlerbeseitigung geht..

          Du hast richtig gelesen aber vermutlich falsch verstanden.

          Ein Projekt zu Optimieren wenn es dann mal funktioniert ist das denkbar falscheste was man machen kann. Ich versuche immer Code zu schreiben der schon ziemlich gut Optimiert ist. Und ich habe eben einen Geschwindigkeitsvorteil erzielt. Ist das so schwer.

          1. Hallo Katie,

            Ein Projekt zu Optimieren wenn es dann mal funktioniert ist das denkbar falscheste was man machen kann. Ich versuche immer Code zu schreiben der schon ziemlich gut Optimiert ist.

            endlich mal jemand, der mir aus der Seele spricht!

            Genau dieser Ansatz ist mir nämlich auch seit vielen Jahren in Fleisch und Blut übergegangen, und oft werde ich deswegen belächelt oder für weltfremd erklärt - sinngemäß mit dem Gedanken, ein schnellerer Rechner sei billiger als die für die Software-Optimierung investierte Zeit.

            Dabei ist das eine Milchmädchenrechnung. Gut optimierten Code zu schreiben ist nicht mehr Aufwand (wenn man sich mal eine entsprechende Denkweise angeeignet hat), aber aus Faulheit auf die immer leistungsfähigere Hardware zu vertrauen, verursacht eine Art Inflation: Die Programmierer schreiben schlampigen Code, weil es ja immer schnellere Rechner gibt, die Hardware-Industrie muss immer schnellere Rechner entwickeln, weil die Software immer behäbiger wird. Und das muss eben nicht sein!

            Schönen Abend noch,
             Martin

            --
            Die Zeit, die man zur Fertigstellung eines Projekts wirklich braucht, ist immer mindestens doppelt so lang wie geplant.
            Wurde dieser Umstand bei der Planung bereits berücksichtigt, gilt das Prinzip der Rekursion.
          2. Hi,

            Du hast richtig gelesen aber vermutlich falsch verstanden.

            Wenn ich einen Geschwindigkeitsunterschied feststelle, brauche ich zwei Geschwindigkeiten, die ich vergleichen kann. Ich sehe nur eine (und zwar die von dem am Ende funktionierendem Code).

            Ein Projekt zu Optimieren wenn es dann mal funktioniert ist das denkbar falscheste was man machen kann. Ich versuche immer Code zu schreiben der schon ziemlich gut Optimiert ist.

            Das unterschreibe ich gerne, hab ich ja aber auch gar nicht bestritten.

            Gruß,
            Felix

            --
            Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jedermann ist überzeugt, dass er genug davon habe.
            René Descartes