Block in Vector kopieren

anli

Hallo!

Ich habe da ein Problem:

Ist es möglich einen ganzen Block Daten auf einmal in einen Vector zu kopieren, so dass der Code dann anschließend ca. so aussieht:

unsigned char GenerateBlock (unsigned short len, unsigned char *block)
    {
        std::vector<unsigned char> data (len);

        data.insert(data.begin(), len, *block);

        return pCommAgent->output(data);
    }

Das kopieren einzelner Zeichen finde ich nicht gerade effektiv....

Danke!

AnLi

Tachyon

So:

std::vector<unsigend char> data(block, block + len);

EDIT:
Achso, nein. So wirds auch zeichenweise kopiert. Aber wo soll das Problem sein? Ist das ein Flaschenhals? Ich kann das nicht wirklich glauben.

simon.gysi

std::vector<unsigned char> v(len);
memcpy(&v[0], block, block + len);

Der C++ Standard garantiert dass die std::vector<T> impl. seine Daten in einen zusammenhängenden Memoryblock abspeichert.

Ob diese Anwendung sinnvoll oder nicht ist, ist eine andere Frage.

Simon

anli

Hallo Tachyon!

Danke, genau so etwas habe ich gesucht... (ist das erste mal, dass ich mit den STL Containerklassen in Berührung komme)

Ich hatte halt keine Lust eine eigene Schleife zu schreiben, wenn es die mit allen möglichen Fehlerüberprüfungen schon irgendow gibt.

Grüße

AnLi

LordJaxom

anli schrieb:

Das kopieren einzelner Zeichen finde ich nicht gerade effektiv....

Findest Du, oder hast Du es gemessen?

<hint>premature optimization</hint>

Simon2

Tachyon schrieb:

...Ist das ein Flaschenhals? Ich kann das nicht wirklich glauben.

Ich auch nicht.
Vermutlich klappt das aber mit einem "memcpy(&data[0], block, len)" (jedenfalls für PODs und wenn man den vector vorher ausreichend groß erzeugt/resized).

Tachyon schrieb:

...So wirds auch zeichenweise kopiert. ...

Bist Du sicher ?
Ich könnte mir vorstellen, dass der entsprechend spezialisierte Konstruktor das durchaus mit memset() macht ... wäre jedenfalls mein Implementationsansatz.

EDIT: Kleiner Fehler

simon.gysi schrieb:

std::vector<unsigned char> v(len);
memcpy(&v[0], block, len); // <- NICHT "block + "

wohl typisch für C++-Programmierer....

Gruß,

Simon2.

LordJaxom

anli schrieb:

Ich hatte halt keine Lust eine eigene Schleife zu schreiben, wenn es die mit allen möglichen Fehlerüberprüfungen schon irgendow gibt.

Welche Fehlerüberprüfungen?

Ich glaube, Dein Wunsch, die Daten en-bloc zu kopieren beruhen auf mangelnder Information deinerseits.

anli

Welche Fehlerüberprüfungen?

Ich glaube, Dein Wunsch, die Daten en-bloc zu kopieren beruhen auf mangelnder Information deinerseits.

... gibt es da keine Überprüfung??? Dann muss ich das halt noch selbst machen... (wie gesagt, bin nicht der C++ und STL Experte)

Sieht aber im code immer noch besser aus als die Zeichenschleife.

Tachyon

Simon2 schrieb:

Tachyon schrieb:

...Ist das ein Flaschenhals? Ich kann das nicht wirklich glauben.

Ich auch nicht.
Vermutlich klappt das aber mit einem "memcpy(&data[0], block, len)" (jedenfalls für PODs und wenn man den vector vorher ausreichend groß erzeugt/resized).

Tachyon schrieb:

...So wirds auch zeichenweise kopiert. ...

Bist Du sicher ?
Ich könnte mir vorstellen, dass der entsprechend spezialisierte Konstruktor das durchaus mit memset() macht ... wäre jedenfalls mein Implementationsansatz.

Gruß,

Simon2.

Jo, mag sein, dass er (der Compiler) für POD's entsprechende Spezialisierungen drin hat. Aber das ist Implementationsabhängig. Verlassen würde ich mich nicht darauf.

LordJaxom

Tachyon schrieb:

Jo, mag sein, dass er (der Compiler) für POD's entsprechende Spezialisierungen drin hat. Aber das ist Implementationsabhängig. Verlassen würde ich mich nicht darauf.

Es gibt auch noch sogenannte Optimierungen, die kompakte Schleifen (und zu nichts anderem expandiert der Aufruf über den Konstruktor) durch entsprechend schnellere Konstrukte ersetzen können.

anli schrieb:

... gibt es da keine Überprüfung???

Ich wiederhole die Frage: Was möchtest Du geprüft haben?

Tachyon

LordJaxom schrieb:

Es gibt auch noch sogenannte Optimierungen, die kompakte Schleifen (und zu nichts anderem expandiert der Aufruf über den Konstruktor) durch entsprechend schnellere Konstrukte ersetzen können.

Jo, schon klar. Aber die Implementierung ist dennoch erstmal Elementweise. Was der Compiler daraus zusammen optimieren kann, steht auf einem anderen Blatt (und hängt auch von der Optimierungsstufe ab).
Btw.: Wieso "sogenannte"?

LordJaxom

Tachyon schrieb:

Btw.: Wieso "sogenannte"?

Weil ich bei diesen Threads oft den Eindruck habe, dass dies nicht bekannt ist, weil fast immer nicht nur nach Mikrooptimierungen gefragt, sondern auch oft direkt auf Möglichkeiten für eben solche hingewiesen wird.

camper

Wenn wir schon dabei sind, der Standardbibliothek bestimmtes ineffizientes Verhalten zu unterstellen, sollte man nicht versäumen, darauf hinzuweisen, dass die memcpy-Variante vorher den gesamten Vektor mit 0 initialisiert. Und das erfolgt - nach der Logik dieses Arguments - ebenfalls elementweise. Insofern düfte es sich also nicht um eine Optimierung handeln.