ich habe folgenden Code:

struct sPaket
{
  int id;
  int length;
  int objID;
  std::vector<int> vec;
};

sPaket msg;

recv(wParam, (char *)&msg, sizeof(msg), 0);

size_t len = msg.vec.size();     //Hier funktioniert es noch
int fehler = msg.vec[0];     //Hier bricht das Programm ab

So, recv() (aus Winsock) liest hier Daten ein. Byte für Byte quasi. Das klappt alles wunderbar, nur als ich jetzt versucht habe, in meinem Struct auch einen std::vector unterzubringen, verließ mich mein Glück. Also ich habe mit Vectoren schon ein bißchen was gemacht, habe aber noch keine wirklich große Erfahrung damit.
Kann mir jemand erklären, warum Zeile 13 funktioniert, das Programm in Zeile 14 aber abstürzt?

Danke schon mal im Voraus!

Also ich habe mit Vectoren schon ein bißchen was gemacht, habe aber noch keine wirklich große Erfahrung damit.
Kann mir jemand erklären, warum Zeile 13 funktioniert, das Programm in Zeile 14 aber abstürzt?

Kannst du dir denken was passiert, wenn man einen Zeiger Byteweise über Programmgrenzen hinweg setzt? Vector arbeitet mit einem dynamisch allozierten Speicherbereich (Als Anwender sieht man davon nichts).

Ok, gäbe es denn eine Möglichkeit, an den Speicher ranzukommen?

EDIT:

Es ist ja nicht so, dass ich nicht schon selbst versucht hätte das zu lösen, aber ich kriegs nicht hin. Ich habe für mein recv() nämlich leider keine Information, wieviel da anokommt, deshalb brauche ich (meiner Meinung nach) einen dynamischen Buffer...

Ok, gäbe es denn eine Möglichkeit, an den Speicher ranzukommen?

Welchen Speicher willst du genau?

Das interne Array kriegst du mit &vec[0] .

Es ist ja nicht so, dass ich nicht schon selbst versucht hätte das zu lösen, aber ich kriegs nicht hin...

Ich habe selbst noch nichts mit Winsock gemacht, aber du kannst nur dann einen Vector verwenden, wenn du ihm von vorne herein die Größe angeben kannst, und selbst dann könnte das Ergebnis undefiniert sein (Ich weiß nicht ob man wirklich manipulierend auf den Bereich, den man über mittels &vec[0] auslesen kann [Zeiger auf den anfangsbereich] zugreifen darf...).

char msg[128];
recv(wParam, &msg[0], 128, 0);

Oder falls du deine Klasse behalten willst, dann so:

struct TPacket
{
 char buf[128];
 int id;
 int length;
 int objID;
};

TPacket packet;
recv(wParam, &packet.msg[0], 128, 0);

Ich kann dir aber nicht sagen, welche Größe man für den Puffer wählen sollte...
Imho könntest du aber auch einen vector nehmen und im CTor nen reserve(laenge) machen und ich glaube, recv gibt die anzahl an bytes zurück, die empfangen wurden.

Also:

struct TPacket
{
 std::vector <char> buf;
 int id;
 int objID;
 TPacket() {buf.reserve(128);}
};

TPacket packet;
recv(wParam, &packet.msg[0], 128, 0);

Allerdings hat die Variante nun nicht mehr sooo viele Vorteile gegenüber eines char buf[x];

bb

(Ich weiß nicht ob man wirklich manipulierend auf den Bereich, den man über mittels &vec[0] auslesen kann [Zeiger auf den anfangsbereich] zugreifen darf...).

Ja, darf man.

asc schrieb:

(Ich weiß nicht ob man wirklich manipulierend auf den Bereich, den man über mittels &vec[0] auslesen kann [Zeiger auf den anfangsbereich] zugreifen darf...).

Ja, darf man.

Was ich nicht glaube (spätestens wenn man die Anzahl an Elementen ändert - auch, wenn man davor den Speicherplatz mit reserve angefordert hat)...
Die Einträge an sich darf man aber logischerweise ändern.
Also müsste man den Vector vor dem ersten Benutzen schon füllen - nur, um die Positionen dann zu überschreiben... Spricht auch nicht gerade für std::vector ^^
Das heißt, dass man doch wieder die Länge braucht, die ich beim letzten Code-Schnipsel weggelassen hatte ^^ Aber wie gesagt würde ich auf vector verzichten - da mir auch kein Grund einfallen würde, ihn hier zu benutzen ^^

PS: Das soll nat. nicht heißen, dass vector scheiße ist und man generell auf ihn verzichten sollte - aber hier in diesem Fall macht das denke ich durchaus Sinn - nicht nur performance-technisch ^^

bb

(spätestens wenn man die Anzahl an Elementen ändert - auch, wenn man davor den Speicherplatz mit reserve angefordert hat)...

Spätestens, wenn man die Anzahl der Elemente ändert, ist was?

Die Einträge an sich darf man aber logischerweise ändern.

Daraus und aus ( &vector[n] == &vector[0] + n ) folgt, dass ich auch die ganze Sequenz ändern darf.

Also müsste man den Vector vor dem ersten Benutzen schon füllen - nur, um die Positionen dann zu überschreiben...

Stimmt, mit resize(). Das dürfte aber auch nicht sonderlich viel kosten.

Das heißt, dass man doch wieder die Länge braucht, die ich beim letzten Code-Schnipsel weggelassen hatte

Du brauchst immer die Länge von Daten variabler Länge. Was hat das hier für eine Bewandnis?

Aber wie gesagt würde ich auf vector verzichten - da mir auch kein Grund einfallen würde, ihn hier zu benutzen

Mir schon: Das automatische Aufräumen.

unskilled schrieb:

(spätestens wenn man die Anzahl an Elementen ändert - auch, wenn man davor den Speicherplatz mit reserve angefordert hat)...

Spätestens, wenn man die Anzahl der Elemente ändert, ist was?

Imho ist so etwas nicht definiert:

void test (int *first)
{
 for (int i(0); i != 500; ++i)
 {
  *first++ = i;
 }
}

std::vector <int> bla;
bla.reserve(500);
test(&bla[0]);

LordJaxom schrieb:

Die Einträge an sich darf man aber logischerweise ändern.

Daraus und aus ( &vector[n] == &vector[0] + n ) folgt, dass ich auch die ganze Sequenz ändern darf.

Aber nur so lange, wie ich die Anzahl der Elemente nicht verändere?!

LordJaxom schrieb:

Das heißt, dass man doch wieder die Länge braucht, die ich beim letzten Code-Schnipsel weggelassen hatte

Du brauchst immer die Länge von Daten variabler Länge. Was hat das hier für eine Bewandnis?

Das ich beim letzten Post bei der Variante mit dem vector die Länge nicht mitgespeichert hab, weil ich davon ausgegangen war, dass wir sie eh haben (vector::size()) - und ich es nur noch mal der Vollständigkeit halber erwähnen wollte...

LordJaxom schrieb:

Aber wie gesagt würde ich auf vector verzichten - da mir auch kein Grund einfallen würde, ihn hier zu benutzen

Mir schon: Das automatische Aufräumen.

Schade nur, dass das kein Vorteil gegenüber char [] ist sondern nur gegenüber char * ansonsten muss ich dir natürlich Recht geben

bb

Imho ist so etwas nicht definiert:

void test (int *first)
{
 for (int i(0); i != 500; ++i)
 {
  *first++ = i;
 }
}

std::vector <int> bla;
bla.reserve(500);
test(&bla[0]);

Wenn Du statt reserve() resize() nimmst, schon.

Daraus und aus ( &vector[n] == &vector[0] + n ) folgt, dass ich auch die ganze Sequenz ändern darf.

Aber nur so lange, wie ich die Anzahl der Elemente nicht verändere?!

Ja? Wenn Du einen Array reallozierst, kannst Du auch nicht die alten Adressen weiterwenden.

Das ich beim letzten Post bei der Variante mit dem vector die Länge nicht mitgespeichert hab, weil ich davon ausgegangen war, dass wir sie eh haben (vector::size()) - und ich es nur noch mal der Vollständigkeit halber erwähnen wollte...

Nun, man müsste zunächst den Vector auf die Größe bringen, die wir maximal empfangen wollen, und danach auf die Größe, die recv tatsächlich zurückgegeben hat. Dann brauchen wir nur noch size().

Schade nur, dass das kein Vorteil gegenüber char [] ist sondern nur gegenüber char * ansonsten muss ich dir natürlich Recht geben

Da hast Du natürlich recht, da hab ich nicht aufgepasst. Aber spätestens, wenn einem auffällt, dass die x Bytes nicht gereicht haben, und man noch einen recv machen muss, um die komplette Nachricht zu empfangen, hat man aber genau dieses Problem :).

das hat zwar den nachteil, dass man jedes mal noch mal alles umkopieren muss, aber da kommt man ja ohnehin nie (?) drum rum...

bb