pixeldaten in vector?



  • in wie weit macht es sinn pixeldaten in einen vector zu speichern?

    typedef struct
    {
      int r,g,b,a;
    } pixel;
    vector<pixel> bild;
    

    einfach guter c++ stil ohne nachteile oder viel zu umständlich/langsam und arrays nehmen?



  • pixi schrieb:

    oder viel zu umständlich/langsam und arrays nehmen?

    nein



  • pixi schrieb:

    in wie weit macht es sinn pixeldaten in einen vector zu speichern?

    typedef struct
    {
      int r,g,b,a;
    } pixel;
    vector<pixel> bild;
    

    einfach guter c++ stil ohne nachteile oder viel zu umständlich/langsam und arrays nehmen?

    Solange du nichts gegenteiliges Beweisen kannst benutze std::vector und erst, wenn es sich herausstellt, dass es tatsächlich zu langsam ist an umstellung denken.

    btw:
    Das sieht sehr nach C aus.. typedef ist unnötig und pixel kommt nach struct..

    struct pixel
    {
      int r,g,b,a;
    };
    vector<pixel> bild;
    


  • drakon schrieb:

    benutze std::vector und erst, wenn es sich herausstellt, dass es tatsächlich zu langsam ist an umstellung denken.

    nö, dann ist was anderes falsch



  • Ein POD in einem std::vector zu verwenden kann gefährlich sein, da PODs ihre skalaren Typen nicht initialisieren. Füge der Struktur mindestens noch einen Standardkonstruktor (und evtl. einen mit 4 Parametern) hinzu. Oder mach daraus gleich eine richtige Klasse mit Gettern und Settern.

    Re_ pixeldaten in vector? schrieb:

    drakon schrieb:

    benutze std::vector und erst, wenn es sich herausstellt, dass es tatsächlich zu langsam ist an umstellung denken.

    nö, dann ist was anderes falsch

    Nicht zwingend. Es ist schon möglich, dass eine std::vector -Implementierung einmal zu langsam ist (und sei es nur, weil die Sicherheitsprüfungen eingeschaltet sind). Aber das dürfte eigentlich nicht viel ausmachen und ein Array sollte wirklich nur verwendet werden, wenn es die letzte Möglichkeit darstellt.


  • Mod

    Nexus schrieb:

    Ein POD in einem std::vector zu verwenden kann gefährlich sein, da PODs ihre skalaren Typen nicht initialisieren.

    Ich habe keine Ahnung, was Initialisierung eines Typen sein soll, aber könntest du vielleicht ein Beispiel zeigen?



  • camper schrieb:

    Nexus schrieb:

    Ein POD in einem std::vector zu verwenden kann gefährlich sein, da PODs ihre skalaren Typen nicht initialisieren.

    Ich habe keine Ahnung, was Initialisierung eines Typen sein soll, aber könntest du vielleicht ein Beispiel zeigen?

    Sorry, sollte "Member" heissen. 😉

    Aber es scheint, als hätte ich mich geirrt; im std::vector werden anscheinend auch PODs vollständig (null-)initialisiert (wahrscheinlich durch einen expliziten Standardkonstruktor-Aufruf). Ich habe aus der Tatsache, dass eine einfache Deklaration eines PODs keine Initialisierung durchführt, fälschlicherweise geschlossen, dass dies auch im std::vector so sei.

    Danke aber für den Hinweis.



  • Nexus schrieb:

    Re_ pixeldaten in vector? schrieb:

    drakon schrieb:

    benutze std::vector und erst, wenn es sich herausstellt, dass es tatsächlich zu langsam ist an umstellung denken.

    nö, dann ist was anderes falsch

    Nicht zwingend. Es ist schon möglich, dass eine std::vector -Implementierung einmal zu langsam ist (und sei es nur, weil die Sicherheitsprüfungen eingeschaltet sind). Aber das dürfte eigentlich nicht viel ausmachen und ein Array sollte wirklich nur verwendet werden, wenn es die letzte Möglichkeit darstellt.

    Die Sicherheitsprüfungen kannst du ausschalten und wenn man annimmt, dass irgendwas zu langsam ist, weil es schlecht programmiert ist, dann kann ja auch der Compiler Arrays schlecht übersetzen können und dann dürfte man die auch nicht verwenden. 🙄

    camper schrieb:

    Nexus schrieb:

    Ein POD in einem std::vector zu verwenden kann gefährlich sein, da PODs ihre skalaren Typen nicht initialisieren.

    Ich habe keine Ahnung, was Initialisierung eines Typen sein soll, aber könntest du vielleicht ein Beispiel zeigen?

    typedef int foo;
    

    😉 :p


Anmelden zum Antworten