3. Fragen zu Windows Bitmap einlesen #2

Fragen zu Windows Bitmap einlesen #2


  • Einen Breakpoint nicht (ich kann leider noch nicht in CodeBlocks den Debugger benutzen, weil ich mich noch nicht ganz mit ERROR: You need to specify a debugger program in the debuggers's settings. auseinander gesetzt habe), aber ich habe eine cout-Ausgabe dort eingeführt, ob diese Wahl überhaupt getroffen wurde. Sie wurde nie aufgerufen.

    Die Zeilen habe ich geändert, weil ich davon ausgegangen bin, das die dortige Abfrage if ((u_val >> 31) & 1) nur zur Entscheidung negativ oder positiv dient. Die weitere Verarbeitung wäre dann nur für eventuell andere Systeme. Dachte ich jedenfalls.

    Ich werd das mal korrigieren.

    EDIT: Aber auch umgeschrieben, scheint es keine negativen Werte zu geben

    uint32_t u_val = bmp_data.at(pos + 0)
                    + (static_cast <uint32_t> (bmp_data.at(pos + 1)) << 8)
                    + (static_cast <uint32_t> (bmp_data.at(pos + 2)) << 16)
                    + (static_cast <uint32_t> (bmp_data.at(pos + 3)) << 24);

    int32_t s_val;
    if ((u_val >> 31) & 1)
    {
        s_val = - static_cast <int32_t> (~u_val) - 1;
    }
    else
    {
        s_val = u_val;
    }

    return s_val;

    Aber vielleicht ist das ja korrekt? Ich bräuchte zum Testen ein Beispiel, wo ganz bestimmt negative Werte enthalten sind?

    0

  • EDIT: Korrektur ist im oberen Beitrag.

    0

  • OK wenn das cout nie anschlägt dann wird es wohl keine negativen Werte gegeben haben in deinen Bitmaps.

    lemon03 schrieb:

    Aber vielleicht ist das ja korrekt? Ich bräuchte zum Testen ein Beispiel, wo ganz bestimmt negative Werte enthalten sind?

    Ja korrekt ist es schon. Es gibt halt top-down und bottom-up BMPs. Standard ist bottom-up und bei denen ist die Höhe positiv.
    D.h. du musst dir irgendwoher top-down BMPs zum Testen besorgen.

    0

  • Jo danke dann 🙂

    Und gute Idee, mal schauen ob man nach top-down BMPs goglen kannn, bzw was findet.

    0

  • Super, hatte mehrere top-down Beispiele gefunden und bei allen wurde der korrekte Wert negativ angezeigt. Danke nochmals.

    0

  • Na super 🙂

    Nochwas...
    Ich würde folgende Änderungen vorschlagen:

    int32_t make_int32 (std::vector <unsigned char> bmp_data, std::size_t pos)
{
    uint32_t u_val = bmp_data.at(pos + 0)
                    + (static_cast <uint32_t> (bmp_data.at(pos + 1)) << 8)
                    + (static_cast <uint32_t> (bmp_data.at(pos + 2)) << 16)
                    + (static_cast <uint32_t> (bmp_data.at(pos + 3)) << 24);

    int32_t s_val;
    if ((u_val >> 31) & 1)
    {
        s_val = - static_cast <int32_t> (~u_val) - 1;
    }
    else
    {
        s_val = u_val;
    }

    return s_val;
}

// =>

int32_t better_make_int32 (std::vector <unsigned char> const& /* 1 */ bmp_data, std::size_t pos)
{
    uint32_t const /* 2 */ u_val = /* 3 */ make_uint32(bmp_data, pos);

    if ((u_val >> 31) & 1)
    {
        return - static_cast <int32_t> (~u_val) - 1; /* 4 */
    }
    else
    {
        return u_val;                                /* 4 */
    }
}

    1: Du solltest nicht den ganzen std::vector kopieren. Das ist sogar im günstigsten Fall (wenig Daten) schon viel langsamer als nötig (dynamische Speicheranforderung!). Und wenn mal viel Daten drinnen wird's richtig langsam.

    2: Lokale Variablen const machen wenn man sie (einfach, ohne grosse Umwege) const machen kann. Damit man gleich sieht dass der Wert der Variable sich nach der Initialisierung nie mehr ändert.

    3: Code-Duplizierung vermeiden.

    4: Mutable-State vermeiden, uninitialisierte Variablen vermeiden.
    Uninitialisierte Variablen vermeiden allerdings nur, wenn man ihnen gleich bei der Initialisierung einen sinnvollen Wert geben kann. Wenn wirklich nur die Wahl besteht zwischen "uninitialisiert" oder "mit Dummy-Wert initialisiert", dann eher uninitialisiert. Meist kann man aber gleich mit dem passenden Wert initialisieren.

    Einige dieser Dinge (z.B. (1)) betreffen auch andere Funktionen, dort natürlich ebenso nachziehen.

    Und wie bei allen Richtlinien gibt es natürlich Ausnahmen. Viel Aufwand zu betreiben um eine dieser Regeln zu befolgen ist nicht immer sinnvoll.

    ----

    Und ich würde vorschlagen die Leerzeichen vor öffnenden Klammern und nach schliessenden Klammern weg zu lassen. Ausnahme: zwischen Keywords und runde Klammer kommt ein Leerzeichen
    Also z.B.

    int x = MeineFunktion(param); // nach MeineFunktion nicht
for (int i = 0; i < x; i++)   // nach for schon
{
    if (static_cast<int32_t>(i * i) < x)  // nach if auch, nach static_cast aber nicht

    usw.

    Das, also wo bei Klammern Leerzeichen gesetzt werden, ist nämlich eine der wenigen Regeln wo sich die meisten Programmierer einig sind. Zumindest ist das mein Eindruck anhand des Codes den ich so sehe.

    EDIT: Copy/Paste/Edit Fehler korrigiert.

    0

  • Und wenn wir schon dabei sind, gleich nochmal weiter:

    int32_t int32_from_uint32(uint32_t u_val)
{
    if ((u_val >> 31) & 1)
        return -static_cast<int32_t>(~u_val) - 1;
    else
        return u_val;
}

int32_t make_int32(std::vector <unsigned char> const& bmp_data, std::size_t pos)
{
    return int32_from_uint32(make_uint32(bmp_data, pos));
}

    EDIT: Copy/Paste/Edit Fehler korrigiert.

    0
  • ?

    Gleichheitszeichen zwischen return und der Variablen finde ich wiederum merkwürdig - mein Compiler auch...

    0

  • war bestimmt nur ein Tippfehler ...

    Ok, danke für die Hinweise. Wenn ich richtig verstanden habe, müssten die drei Funktionen dann so aussehen?:

    uint16_t make_uint16(std::vector <unsigned char> const &bmp_data, std::size_t pos)
{
    uint16_t const u_val = bmp_data.at(pos + 0)
                    + (static_cast<uint16_t>(bmp_data.at(pos + 1)) << 8);

    return u_val;
}

uint32_t make_uint32(std::vector <unsigned char> const &bmp_data, std::size_t pos)
{
    uint32_t const u_val = bmp_data.at(pos + 0)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 1)) << 8)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 2)) << 16)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 3)) << 24);

    return u_val;
}

int32_t make_int32(std::vector <unsigned char> const &bmp_data, std::size_t pos)
{
    uint32_t const u_val = make_uint32 (bmp_data, pos);

    if ((u_val >> 31) & 1)
    {
        return -static_cast<int32_t>(~u_val) - 1;
    }
    else
    {
        return u_val;
    }
}

    Nur das doppelt ausschreiben in Deinem letzten Beitrag habe ich nicht ganz verstanden?

    ---

    Ich hoffe, das wird jetzt nicht zuviel, aber ich hätte noch ein anderes Anliegen. Und zwar bin ich mit meiner switch-Lösung nicht ganz zufrieden. Ich würde lieber einen Funktionszeiger nehmen, bekomme das aber nicht hin.

    Vorgestellt habe ich mir, das hier der second-Wert das Argument für den Zeiger sein soll. Welcher Typ das sein muss, ist mir unklar.

    struct Head //Kopf
{
    static const auto Size = 4;
    std::array <std::pair <std::string, int>, Size> bType
    {
        {
            { "bfType", 1 }, //uint16_t
            { "bfSize", 2 }, //uint32_t
            { "bfReserved", 2 },
            { "bfOffbits", 2 }
        }
    };
    std::array <int, Size> data;

} head;

//int (*make_data)(std::vector <unsigned char>, std::size_t);

    Unklar ist mir auch, wie eine Funktion mit diesem Argument dann aufgerufen wird. Ich hatte bisher nur einmal mit Funktionszeigern zu tun, mir fehlt die Übung und ich kann den ersten Einsatz nicht für diesen Fall nachvollziehen.

    0

  • wob schrieb:

    Gleichheitszeichen zwischen return und der Variablen finde ich wiederum merkwürdig - mein Compiler auch...

    Danke, hab's korrigiert.

    0

  • lemon03 schrieb:

    (...)müssten die drei Funktionen dann so aussehen?:

    uint16_t make_uint16(std::vector <unsigned char> const &bmp_data, std::size_t pos)
{
    uint16_t const u_val = bmp_data.at(pos + 0)
                    + (static_cast<uint16_t>(bmp_data.at(pos + 1)) << 8);

    return u_val;
}

uint32_t make_uint32(std::vector <unsigned char> const &bmp_data, std::size_t pos)
{
    uint32_t const u_val = bmp_data.at(pos + 0)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 1)) << 8)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 2)) << 16)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 3)) << 24);

    return u_val;
}

int32_t make_int32(std::vector <unsigned char> const &bmp_data, std::size_t pos)
{
    uint32_t const u_val = make_uint32 (bmp_data, pos);

    if ((u_val >> 31) & 1)
    {
        return -static_cast<int32_t>(~u_val) - 1;
    }
    else
    {
        return u_val;
    }
}

    Sieht gut aus würde ich sagen.

    lemon03 schrieb:

    Nur das doppelt ausschreiben in Deinem letzten Beitrag habe ich nicht ganz verstanden?

    Keine ahnung was du meinst. Steh vermutlich grad auf dem Schlauch 🙂

    0

  • Danke. Meinte dies:

    int32_t int32_from_uint32(uint32_t u_val)
{
    if ((u_val >> 31) & 1)
        return -static_cast<int32_t>(~u_val) - 1;
    else
        return u_val;
}

int32_t make_int32(std::vector <unsigned char> const& bmp_data, std::size_t pos)
{
    return int32_from_uint32(make_uint32(bmp_data, pos));
}

    Mir scheint das da zwei Funktionsteile genommen und daraus zwei Funktionen gemacht wurden?

    0

  • Ja, genau. Und?

    0

  • Dann würde aus

    uint32_t make_uint32(std::vector <unsigned char> const &bmp_data, std::size_t pos)
{
    const uint32_t u_val = bmp_data.at(pos + 0)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 1)) << 8)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 2)) << 16)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 3)) << 24);

    return u_val;
}

int32_t make_int32(std::vector <unsigned char> const &bmp_data, std::size_t pos)
{
    const uint32_t u_val = make_uint32(bmp_data, pos);
    if ((u_val >> 31) & 1)
    {
        return -static_cast<int32_t>(~u_val) - 1;
    }
    else
    {
        return u_val;
    }
}

    -->

    uint32_t make_uint32(std::vector <unsigned char> const &bmp_data, std::size_t pos)
{
    const uint32_t u_val = bmp_data.at(pos + 0)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 1)) << 8)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 2)) << 16)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 3)) << 24);

    return u_val;
}

int32_t int32_from_uint32(uint32_t u_val)
{
    if ((u_val >> 31) & 1)
        return -static_cast<int32_t>(~u_val) - 1;
    else
        return u_val;
}

int32_t make_int32(std::vector <unsigned char> const& bmp_data, std::size_t pos)
{
    return int32_from_uint32(make_uint32(bmp_data, pos));
}

    Die Aufsplittung auf zwei Funktionen verstehe ich vom Nutzen her nicht. Da die einzelnen Teile nirgendwo als in dieser Funktion gebraucht werden, finde ich das irgendwie überflüssig?

    0
  • ?

    lemon03 schrieb:

    Die Aufsplittung auf zwei Funktionen verstehe ich vom Nutzen her nicht. Da die einzelnen Teile nirgendwo als in dieser Funktion gebraucht werden, finde ich das irgendwie überflüssig?

    Der Code wird übersichtlicher und du kannst die einzelnen Funktionen einfacher testen. Eine Funktion sollte für genau eine Sache verantwortlich sein, diese darf gerne klein sein.

    0

  • Das mag allgemein so stimmen, aber doch im obigen Fall nicht?

    Der erst Block mit zwei Funktionen ist doch leichter auf einen Blick zu erfassen, als der untere mit drei verschachtelten Funktionen?

    Und im Programm werden drei Werte durch drei ganz einfache Funktionen bestimmt, warum sollte man diese drei einfachen Funktionen auf vier aufsplitten?

    0

  • wob schrieb:

    und du kannst die einzelnen Funktionen einfacher testen.

    Da die oberen Funktionen alle voneinander abhängig sind, kann man doch gar nicht die einzelnen Funktionen testen, ohne auch die anderen zu testen?

    Also warum nicht nur eine Funktion testen, statt zwei?

    0

  • Also sorry, wollte nicht aufmüpfig erscheinen. Bin ja froh, wenn man mir hilft und erklärt.

    Ich würde gerne noch mal auf den Funktionszeiger zurück kommen, ob das hier möglich und sinnvoll ist. Vorgestellt habe ich mir das mit sozusagen Pseudocode etwa so:

    int (*make_dec)(std::vector <unsigned char> const, std::size_t); //hier const richtig?

uint16_t m_uint16(std::vector <unsigned char> const &bmp_data, std::size_t pos)
{
    const uint16_t u_val = bmp_data.at(pos + 0)
                    + (static_cast<uint16_t>(bmp_data.at(pos + 1)) << 8);

    return u_val;
}

uint32_t m_uint32(std::vector <unsigned char> const &bmp_data, std::size_t pos)
{
    const uint32_t u_val = bmp_data.at(pos + 0)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 1)) << 8)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 2)) << 16)
                    + (static_cast<uint32_t>(bmp_data.at(pos + 3)) << 24);

    return u_val;
}

int32_t m_int32(std::vector <unsigned char> const &bmp_data, std::size_t pos)
{
    const uint32_t u_val = make_uint32(bmp_data, pos);
    if ((u_val >> 31) & 1)
    {
        return -static_cast<int32_t>(~u_val) - 1;
    }
    else
    {
        return u_val;
    }
}

struct Head //Kopf
{
    static const auto Size = 4;
    std::array <std::pair <std::string, |Typ?|>, Size> bType
    {
        {
            { "bfType",     m_uint16 }, //uint16_t
            { "bfSize",     m_uint32 }, //uint32_t
            { "bfReserved", m_uint32 },
            { "bfOffbits",  m_uint32 }
        }
    };
    std::array <int, Size> data;

} head;

head.data.at(i) = Funktionsaufruf mit <head.bType.at(i).second>;

    Ich weiß leider nicht, wie ich das korrekt ausformuliere.

    0

  • lemon03 schrieb:

    Da die oberen Funktionen alle voneinander abhängig sind, kann man doch gar nicht die einzelnen Funktionen testen, ohne auch die anderen zu testen?

    Naja die sind eben nicht voneinander abhängig. (Also schon die eine von der anderen, aber nicht die andere von der einen.)
    Wie man aus einem uint32_t mit nem 2s complement Bitmuster eines signed Wertes einen int32_t (mit diesem signed Wert) macht, und zwar plattformunabhängig und so dass per C++ Standard garantiert das Ergebnis passt, ist nicht davon abhängig wo man dieses Bitmuster her hat.
    D.h. die uint -> int Funktion kann man super testen.

    Weiters könnte man sie in ein Template umbauen, so dass sie für alle Bitbreiten funktioniert. Dann kann man sie in anderen make_intXX Funktionen wiederverwenden. Bzw. allgemein könnte es Stellen geben wo man die selbe Funktion braucht.

    Und es wird leichter dadurch zu lesen. z.B. schonmal dadurch dass die Funktion jetzt einen Namen hat. Wenn man diesen gut wählt (und nicht so wie du kryptische Abkürzungen wie "m_uint32" verwendet ;)), dann sagt alleine der Name schon was die Funktion macht. Wenn ich nur verstehen will was der Code macht brauche ich mir also nichtmal ansehen wie die Funktion implementiert ist. (Das müsste ich nur, wenn ich überprüfen will ob die Implementierung korrekt ist. Und auch da ist es besser viele kleinere Teile zu haben, da man die Funktion einer Funktion oder Klasse viel leichter überprüfen kann wenn diese klein ist und nur wenig tut.)

    ps:

    lemon03 schrieb:

    Ich würde gerne noch mal auf den Funktionszeiger zurück kommen,

    Jo, sorry. Dafür brauch ich ne ruhige Minute (die ich jetzt nicht habe und auch gestern nicht hatte) 🙂

    0

  • hustbaer schrieb:

    Jo, sorry. Dafür brauch ich ne ruhige Minute (die ich jetzt nicht habe und auch gestern nicht hatte) 🙂

    Kein Ding 😉 Und danke nochmals für die Erklärung.

    0
Anmelden zum Antworten