Sourcecodes von Websites teilw. fehlerhaft geladen

Shade Of Mine

status = ::recv(m_sock, buf, MAXRECV, 0); 
    if(status>0 || status != SOCKET_ERROR) 
    { 
        s.append(buf); 
    }

recv tut nicht 0 terminieren tun

unskilled

Shade Of Mine schrieb:

status = ::recv(m_sock, buf, MAXRECV, 0); 
    if(status>0 || status != SOCKET_ERROR) 
    { 
        s.append(buf); 
    }

recv tut nicht 0 terminieren tun

dafür hat er ja obendrüber das mit dem memset gemacht gehabt... das war also nicht der fehler (abgesehen davon, was passiert wenn recv auch [c]maxrecv[c] zeichen empfängt - aber ok ^^

bb

unskilled schrieb:

was passiert wenn recv auch [c]maxrecv[c] zeichen empfängt

genau.

Sinthoras

Vielen, vielen Dank für dich vielen Antworten und die große Mühe!

@unskilled:
Speziell für Deine Mühe vielen Dank.
Die recv-Funktion hab ich aus dem Buch abgeschrieben. Hat auch bisher getan, was sie sollte.
Deine tut es auch, ich nehm dann wohl die, wenn es so richtig ist...
Danke.

Was ich immernoch nicht verstanden habe: Wieso bekomme ich bei ein und derselben Seite mal den richtigen Quellcode und mal noch ein paar fehlerhafte Zeichen dazu?
Kommt er nur manchmal mit der Formatierung klar?!? Das kommt mir wirklich seltsam vor. Wenn es wenigstens immer oder nie falsch wäre...

Edit:
Der Quelltext ist formatiert nach iso-8859-1.
Kann ich da bei string bleiben?
(Ich hab leider null Ahnung von Stringkodierungen...)

unskilled

Sinthoras schrieb:

Edit:
Der Quelltext ist formatiert nach iso-8859-1.
Kann ich da bei string bleiben?
(Ich hab leider null Ahnung von Stringkodierungen...)

Ich leider auch nicht ^^
musste mal wikipedia gucken ^^
ansonsten weiß ich leider nicht, warum es mal falsch und mal richtig ist... dann konnte es auch eher weniger an der fkt liegen... ><

bb

hustbaer

Sinthoras schrieb:

// socket.h
#ifndef _SOCKET_H_
#define _SOCKET_H_

#include <winsock.h>
#include <string>
#include <windows.h>
#include <io.h>

const int MAXRECV = 1024;

class Socket
{
    private:
    int m_sock;
    sockaddr_in m_addr;

    public:
    Socket();
    virtual ~Socket();

    bool create();
    bool bind(const int port);
    //bool listen();
    //bool accept();
    bool connect(const std::string host, const int port);

    bool send(const std::string) const; // ???
    int recv(std::string&) const; // ???

    bool close() const; // ???

    void cleanup() const; // ???
    bool is_valid() const {return m_sock != -1;}
};

#endif

Überdenk mal deinen eigensinnigen Umgang mit const
Nicht alles was sich als const compilieren lässt sollte man auch const machen. Dinge wie send/recv bzw. read/write würde ich auf keinen Fall const machen -- schliesslich haben diese Funktionen ja durchaus nicht zu vernachlässigende Seiteneffekte.

Einzig ein "read" in einer File-Klasse die keinen "File-Pointer" verwaltet (bzw. eine "Variante" von Read die diesen File-Pointer nicht ändert) würde ich als const ansehen, da sich dadurch der Zustand des Objektes ja wirklich nicht ändert.

Anders gesagt: const sollten IMO nur Dinge sein, bei denen es keine Rolle spielt ob man sie wiederholt, oder ganz weglässt (ganz weglassen geht natürlich nur sofern man das Ergebnis nicht auswertet). Und bei send/recv/close/... auf einen Socket ist das ja ganz sicher nicht gegeben.

Sinthoras

Ich hab gelesen, ich solle das alles const machen. Aber ich muss gestehen, ich weiß nicht, warum...
Könntest du mir erklären, was hier das Problem ist bzw. was sich dadurch ändert?
Ich dachte, ich sage dem Compiler damit nur, dass meine Methode das Objekt nicht ändert. Nicht?

Davon ab: Weiß vielleicht doch jemand, warum der Quelltext mal richtig, mal falsch geladen wird?

LG

Sinthoras schrieb:

Davon ab: Weiß vielleicht doch jemand, warum der Quelltext mal richtig, mal falsch geladen wird?

steht doch schon da oben: du liest MAXRECV bytes ein und hast dann keine abschließende 0 mehr. beim anhängen an den string hängts dann vom zufall ab, wo der string terminiert wird (nämlich bei der ersten zufällig gefundenen 0 im speicher hinter dem string).

versuch doch mal mit

status = ::recv(m_sock, buf, MAXRECV - 1, 0);

dann wird die 0 auch nicht überschrieben.

unskilled

Sinthoras schrieb:

@unskilled:
[...]
Die recv-Funktion hab ich aus dem Buch abgeschrieben. Hat auch bisher getan, was sie sollte.
Deine tut es auch, ich nehm dann wohl die, wenn es so richtig ist...
Danke.

Was ich immernoch nicht verstanden habe: Wieso bekomme ich bei ein und derselben Seite mal den richtigen Quellcode und mal noch ein paar fehlerhafte Zeichen dazu?

Was nun? Hast du es mit meiner recv-Funktion versucht oder mit der, die du davor hattest? (btw glaub ich dir nicht, dass du die so in nem Buch gefunden hast...)
Falls du noch immer die offensichtlich falsche Methode (kam ja nun schon von mind. 3 Leuten), dann solltest du evtl mal nachdenken, ob du verstanden hast, was deine Funktion macht und vll doch mal die Beiträge lesen...

Zum const-Umgang:

Sinthoras schrieb:

Ich dachte, ich sage dem Compiler damit nur, dass meine Methode das Objekt nicht ändert. Nicht?

Prinzipiell schon...
Aber ich halte so etwas auch für sehr sinnvoll:

hustbaer schrieb:

Anders gesagt: const sollten IMO nur Dinge sein, bei denen es keine Rolle spielt ob man sie wiederholt, oder ganz weglässt (ganz weglassen geht natürlich nur sofern man das Ergebnis nicht auswertet). Und bei send/recv/close/... auf einen Socket ist das ja ganz sicher nicht gegeben.

Hat hustbaer eigtl schon alles dazu gesagt...

bb

C++ Forumbot

Dieser Thread wurde von Moderator/in Phoemuex aus dem Forum C++ in das Forum WinAPI verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Sinthoras

diagnostiker schrieb:

Sinthoras schrieb:

Davon ab: Weiß vielleicht doch jemand, warum der Quelltext mal richtig, mal falsch geladen wird?

steht doch schon da oben: du liest MAXRECV bytes ein und hast dann keine abschließende 0 mehr. beim anhängen an den string hängts dann vom zufall ab, wo der string terminiert wird (nämlich bei der ersten zufällig gefundenen 0 im speicher hinter dem string).

versuch doch mal mit
status = ::recv(m_sock, buf, MAXRECV - 1, 0);
dann wird die 0 auch nicht überschrieben.

Danke. Das Problem hatte ich davor nicht verstanden. Jetzt schon, danke.

unskilled schrieb:

btw glaub ich dir nicht, dass du die so in nem Buch gefunden hast...

Darfst du getrost glauben. Ausgedacht hab ich's mir nicht, sonst hätte ich mir schon überlegt, was das soll...
(J. Wolf, C++ von A bis Z, S.926 u. S.928 ff.)

Hab den Fehler jetzt behoben und ich denke, es geht jetzt.
Vielen Dank an alle, die mir geholfen haben.

LG
Sinthoras

Sinthoras schrieb:

(J. Wolf, C++ von A bis Z, S.926 u. S.928 ff.)

dieses Buch ist als sehr schlechtes bekannt