Problem mit recv und endlos schleife



  • Ich persönlich bin noch recht gut mit c unterwegs. Mit deinem Code komm ich zurecht, obwohl ich C++ nur halbherzig programmiere.

    Ich glaube, dass ist in etwa seine Kritik. Du benutzt ne Mischung von C und C++... C deßhalb, weil ich dachte das in C++ nicht mehr gemalloced wird.

    Oder hab ich jetzt noch was derb fatales übersehen?



  • man kann auch new und delete nehmen aber um realloc kommt nicht rum zu in verbindung mit char*, zum dem habe ich mir angewöhnt die Vorteile beider sprachen zu nutzen. Klassen und Templates von C++ und den Rest von C. Spart rechenzeit und ist trotzdem sehr übersichtlich und über new und delete lässt sich drüber streiten.



  • Ich programmiere fast ausschließlich in C++ und finde den Code auch grausam. Wenn man C++ nutzt, dann sollte man auch die entsprechenden Mittel einsetzen, die es einem bietet.

    Das fängt schon bei diesem hässlichen Makro an. Makros sollte man übrigens immer in Großbuchstaben schreiben, damit man nicht wohlmöglich irgendwann mal ein int buffersize; in int 256; ersetzt bekommt...

    Und durch weitere Abstraktionen, etc. hätte man sicher auch noch das ein odere andere close in einem Destruktor packen können. Netter Nebeneffekt: Die Verbindung wird definitiv geschlossen.

    Tuxist schrieb:

    man kann auch new und delete nehmen aber um realloc kommt nicht rum zu in verbindung mit char*, zum dem habe ich mir angewöhnt die Vorteile beider sprachen zu nutzen. Klassen und Templates von C++ und den Rest von C. Spart rechenzeit und ist trotzdem sehr übersichtlich und über new und delete lässt sich drüber streiten.

    Man kann auch std::string nehmen und spart sich beides.

    Im übrigen glaube ich nicht, dass dein Programm so performancekritisch ist, dass du überhaupt einen Unterschied merken würdest. Tatsächlich würdest du sogar noch schneller mit deinem Programm voran kommen und hättest dann Zeit dort zu optimieren wo es tatsächlich eng wird.



  • Tuxist schrieb:

    Spart rechenzeit

    Wohl kaum. Selbst wenn, du würdest es nicht mal merken.

    Tuxist schrieb:

    und ist trotzdem sehr übersichtlich

    Dein Code ist das hässlichste Stück Scheiße, das ich seit Wochen gesehen habe. Sogar die schlechtesten Anfänger schreiben schöneren Code, wenn sie nicht gerade ein J.W. Buch haben.

    Tuxist schrieb:

    und über new und delete lässt sich drüber streiten.

    So viel Mist in einem Satz, Gratz! 👍



  • sdfsdfsdf:

    mit dem Marco haste recht habe ich übersehen und close kann man auch Deconstructor
    paltzieren 🙄 . Aber std::string mit C funktionen ist ein Interessantes Konstrukt. Ahja der kernel und die glibc sind in c geschrieben 😉

    314159265358979:
    New ist vergleichbar mit Malloc.
    delete ist vergleichbar mit free.

    Schau mal GCC nach dar wird die das auffallen es nur kürzer weil der Rückgabe type entsprechend zurückgegeben wird 😉



  • Tuxist schrieb:

    Deconstructor

    Es heißt Destruktor.

    Tuxist schrieb:

    Ahja der kernel und die glibc sind in c geschrieben 😉

    Zusammenhang zum Thread = 0.

    Tuxist schrieb:

    New ist vergleichbar mit Malloc.
    delete ist vergleichbar mit free.

    Nein. new ruft Konstruktoren auf, delete Destruktoren.

    Tuxist schrieb:

    Schau mal GCC nach

    Ich brauche nichts nachsehen, ich weiß es besser als du.

    Tuxist schrieb:

    dar wird die das auffallen es nur kürzer weil der Rückgabe type entsprechend zurückgegeben wird 😉

    Siehe oben. Du hast new und delete nicht verstanden.

    P.S.: Und schreib bitte Deutsch, es fällt mir unglaublich schwer, deine Posts zu entziffern.



  • Der Kernel operiert auch auf Hardware Ebene und muss zudem mit stark begrenzten Ressourcen auskommen. Das heißt nicht, dass es nicht auch in C++ möglich wäre, aber es macht einfach nicht viel Sinn.

    Und das die C Bibliothek in C geschrieben ist. Tja, muss wohl was damit zu tun haben, dass es eine C und keine C++ Bibliothek ist (die C++ Bibliothek ist in C++ geschrieben).

    Sind also alles keine Argumente dagegen. Ganz im Gegenteil. Viele Fehler im Kernel, etc. hätte man mit C++ verhindern können - man hatte aber einfach keine Wahl. Du hast aber die Wahl!



  • Nein. new ruft Konstruktoren auf, delete Destruktoren.

    ja wenn man ein klasse verwendet:

    Bezogen auf eine Klasse stimmt das, aber es ist auch new int oder new char[255] möglich und in diesem Fall wir es nur gewrapped.

    Natürlich ist auch eine

    Class class = new Class(); möglich hier wird die klasse mit einem Zeiger Initialisiert. Den man natürlich auch wieder löschen kann.

    new reserviert Speicher und Delete gibt ihn wieder frei. Eigentlich ganz einfach.



  • Mit std::string kannst du auf diesen ganzen quatsch verzichten. Die C Funktionen brauchst du dann gar nicht mehr. Mit Ausnahme der Socket-Funktionen, aber dafür hat std::string die Funktion c_str und alles ist gut.

    In C++ könnte man dann noch Smart Pointer verwenden, und braucht sich um das delete nicht mal mehr kümmern. Das Programm ist dadurch um einiges robuster und sicherer! Und das ist nicht zuletzt gerade bei einem Webserver wichtig, der ja möglichst immer erreichbar sein soll.

    Aber mach mal wie du denkst. Irgendwann wirst du an einem Punkt sein, wo du merkst, das etwas schief läuft. Viel Spaß beim Suchen wünsch ich dir schon mal. Vielleicht denkst du dann ja nochmal an uns. 😃



  • c_str gibt einen const char * zurück. Ist bißchen blöd wenn man reinschreiben muss :-p.



  • Tuxist schrieb:

    c_str gibt einen const char * zurück. Ist bißchen blöd wenn man reinschreiben muss :-p.

    std::vector<char> und dann ggf. in std::string. Glaub mir, du kannst dir das Leben so viel einfacher machen. 😉



  • Wobei das natürlich nur geht, wenn nichts angehängt, etc. wird. In dem Fall kann man zur Not auch einen temporären char * verwenden und ihn einfach wieder in ein std::string umwandeln. Geht auch und ist um einiges schmerzfreier.



  • Tuxist schrieb:

    aber es ist auch new int oder new char[255] möglich und in diesem Fall wir es nur gewrapped.

    new benutzt man mit primitiven Typen so gut wie nie, mit Arrays schon gar nicht. Und dass da irgendwas gewrapped wird, steht nirgens im Standard.

    Tuxist schrieb:

    c_str gibt einen const char * zurück. Ist bißchen blöd wenn man reinschreiben muss :-p.

    &str[0]
    

    Wieder ist das Problem nicht C++, sondern deine Ahnunglosigkeit.

    sdfsdfsdf schrieb:

    std::vector<char> und dann ggf. in std::string.

    Schwachsinn.

    @Tuxist: An deiner Stelle würde ich ganz schnell leise sein und vielleicht diesen komischen 314159265358979 bitten, den Code zu verbessern. Das hier führt zu nichts.



  • std::string getHttp(int sock)
    {
    	std::string data;
    	std::vector<char> buffer(BUF_SIZE);
    
    	while (recv(sock, &buffer[0], BUF_SIZE, 0) > 0)
    		data += std::string(buffer.begin(), buffer.end());
    
    	close(sock); 
    
    	return data;
    }
    

    Ungetestet.

    314159265358979 schrieb:

    Tuxist schrieb:

    c_str gibt einen const char * zurück. Ist bißchen blöd wenn man reinschreiben muss :-p.

    &str[0]
    

    Schwachsinn.



  • sdfsdfsdf schrieb:

    data += std::string(buffer.begin(), buffer.end());
    

    Schwachsinn, eine sinnlose Kopie.



  • Und wie würdest du es lösen? Stattdessen std::vector vergrößern und recv die neue Adresse übergeben?

    Das Ergebnis ist nicht viel anders, aber umständlicher. Ich bin trotzdem gespannt 🙂



  • Statt dem vector nen String nehmen und direkt += nehmen, ohne einen neuen String zu konstruieren.



  • new char[255] = ist völlig normal denn ein string ist nur ein array aus char's, der unterschied zum c++ string ist, das der c++ string typen sicher ist und eine automatische größen anpassung hat. Denn c++ basiert auf c. 😉



  • Tuxist schrieb:

    new char[255] = ist völlig normal

    Schweig, von dir kommt nur noch Scheiße.



  • Statt dem vector nen String nehmen und direkt += nehmen, ohne einen neuen String zu konstruieren.

    würde gehen aber das ding muss auch wieder kleiner werden wenn ich ein String nehme kann ich keinen memmove oder ähnliches machen beim parsen der Daten, das würde bedeuten das ist mit find und substr arbeiten müsste was sehr viel last erzeugt 😃

    lighttpd ist in c geschrieben
    apache ist in c geschrieben
    minihttpd ist in c geschrieben
    nynx ist in c++ geschrieben .....

    Das hat schon einen Grund, zu mal der code eh c clastig.. pthread.. sockets.. fork.. .

    Und warum sollte man nicht noch die vorteile von cpp nutzen und die nachteile umgehen.

    schon mal doom3 quellcode angesehen ?

    da wirst du das gleiche festellen.

    oder in tinyxml ?


Anmelden zum Antworten