Binärdaten über Sockets empfangen?

BlackCubeX

Danke für eure ganzen Antworten, ich finds lustig, wie hier auf die kleinste Frage immer gleich eine riesen Diskussion ausbricht ^^
Sowas wie von Wutz hätte ich eigentlich erwartet, aber das von E0P sirht auch interressant aus und wird bestimmt noc Verwendung finden
Ich hab die Sache inzwischen übrigens einfach mit

outfile.write(buffer, count);

gelöst

LG
BCX

cooky451

BlackCubeX schrieb:

Danke für eure ganzen Antworten, ich finds lustig, wie hier auf die kleinste Frage immer gleich eine riesen Diskussion ausbricht ^^

Das ist der Sinn eines Forums.

BlackCubeX schrieb:

aber das von E0P sirht auch interressant aus und wird bestimmt noc Verwendung finden

Lieber nicht.

BlackCubeX schrieb:

Ich hab die Sache inzwischen übrigens einfach mit
outfile.write(buffer, count);
gelöst

Also meine Variante.

rüdiger

Wutz schrieb:

unsigned char buffer[1024],*b=0;
size_t p=0;
while( (count = recv( sock, buffer, 1024, 0))>0 )
{
  b=realloc(b,p+count);
  memcpy(b+p,buffer,count);
  p+=count;
}

Du verwendest realloc falsch http://www.c-plusplus.net/forum/206606
Außerdem ist ein realloc pro recv keine gute Allokierungsstrategie.

Wutz

Ich verwende realloc richtig.
Und deine "Strategie" der Vermeidung von vielen realloc ist subjektiv, scheitert ein realloc mit diesen minimalen Raten irgendwann mal, hast du mit deinem Programm eh ganz andere Probleme.
Deswegen kann man auch statt *b=0 *b=malloc(100000000) verwenden, was aber mit der Frage nichts zu tun hat.

rüdiger

Wutz schrieb:

Ich verwende realloc richtig.

Nein, siehe Link (3.2). realloc kann NULL zurück liefern und das ist nicht mal so unwahrscheinlich, wenn man größere Daten über http laden will. Dann hast du n Speicherlack, versuchst auf NULL zu kopieren, etc.

Wutz

Kannst du lesen? Nein kannst du nicht, zumindest nicht bis zum Ende meines Beitrages.

EOP

cooky451 schrieb:

BlackCubeX schrieb:

aber das von E0P sirht auch interressant aus und wird bestimmt noc Verwendung finden

Lieber nicht.

Na was denn? Das ist ordentlich programmiert bis auf den Test, ob tmp NULL ist.

cooky451

EOP schrieb:

Na was denn? Das ist ordentlich programmiert bis auf den Test, ob tmp NULL ist.

Ja.. bis auf:

- Es ist C++ und kein C, und wenn man C++ hat sollte man lieber gleich std::vector<char> nutzen.

Aber nehmen wir mal an es wäre C und du hättest malloc/free statt new/delete genutzt:

- Alles was du empfängst muss mit so einem Puffer sinnloserweise ein Mal mehr kopiert werden.
- p sollte const char* sein. (Oder gleich const void*)
- amount sollte gleich size_t sein.
- Du machst sinnloserweise eine Nullterminierung im Puffer selbst.
- Du könntest gleich auf m_data_size+amount >(=) m_buf_size testen, entsprechend Speicher reservieren und den alten Kram kopieren, dann würdest du einiges an Coderedundanz sparen und das Ganze wäre viel übersichtlicher.
- Du solltest realloc nutzen. ( )

EOP

Das mit const ist ok.

Der Hintergrund wieso ich die ganze Klasse überhaupt geschrieben hatte ist der, daß ich auch "transfer-encoding: chunked" mit binären Daten runterladen und nach Schlüsselworten durchsuchen musste.

Und welchen Vorteil hätte ich wenn ich malloc statt new benutzen würde? Erschließt sich mir nicht so ohne weiteres.

Nullterminierung ist deshalb weil ich je nach übertragenem mime-Typ dann mit strstr suche. (Jetzt nicht auch noch an strstr rummeckern!)

rüdiger

Wutz schrieb:

Kannst du lesen? Nein kannst du nicht, zumindest nicht bis zum Ende meines Beitrages.

Wer muss denn gleich persönlich werden. Es ist eben nicht unrealistisch das realloc fehlschlägt. Es geht um eine HTTP-Implementierung und da ziehen Leute gerne mal ein DVD-Image oder andere große Dateien die möglicherweise nicht in den Speicher passen. Wenn du gerne Code schreibst, der dir in Fehlersituationen um die Ohren fliegt, dann bitte tu das. Aber das solltest du nicht anderen Leuten empfehlen.

cooky451

EOP schrieb:

Das mit const ist ok.

Was heißt "ok"? Nein, es ist nicht ok. Oder alles ist ok. Jedenfalls hat das const in der Meckerhierarchie keine Sonderstellung.

EOP schrieb:

Der Hintergrund wieso ich die ganze Klasse überhaupt geschrieben hatte ist der, daß ich auch "transfer-encoding: chunked" mit binären Daten runterladen und nach Schlüsselworten durchsuchen musste.

Dafür sieht die Klasse aber nicht gemacht aus.

EOP schrieb:

Und welchen Vorteil hätte ich wenn ich malloc statt new benutzen würde? Erschließt sich mir nicht so ohne weiteres.

Keinen, aber es wäre eben C.

EOP schrieb:

Nullterminierung ist deshalb weil ich je nach übertragenem mime-Typ dann mit strstr suche. (Jetzt nicht auch noch an strstr rummeckern!)

Dann baut man das aber nicht in den Puffer, sondern regelt das von einer anderen Stelle aus. Eine Pufferklasse ist dafür einfach nicht zuständig. (Es sei denn, sie soll einen String darstellen.)

Und strstr ist natürlich auch suboptimal.

EOP

cooky451 schrieb:

Und strstr ist natürlich auch suboptimal.

Wusst ich's doch.

Ist ja auch nur AppendData, hat bis dahin nix mit "transfer-encoding: chunked"-auflösen zu tun.

Und eigentlich ging's ja nur darum, dem OP zu zeigen wie man memcpy benutzt.

Wenn C++ C-Funktionen unterstützt und die imho schneller sind, dann benutz ich die eben. Mal ganz abgesehen davon, daß ich mit C angefangen hab und C immer noch cool finde.