Problem mit recv und endlos schleife

[sdfsdfsdf]

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!

[Tuxist]

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.

[sdfsdfsdf]

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.

[Tuxist]

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

[sdfsdfsdf]

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.

[sdfsdfsdf]

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.

[314159265358979]

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.

[sdfsdfsdf]

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.

[314159265358979]

sdfsdfsdf schrieb:

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

Schwachsinn, eine sinnlose Kopie.

[sdfsdfsdf]

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

[314159265358979]

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

[Tuxist]

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.

[314159265358979]

Tuxist schrieb:

new char[255] = ist völlig normal

Schweig, von dir kommt nur noch Scheiße.

[Tuxist]

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 ?

[sdfsdfsdf]

314159265358979 schrieb:

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

Ja, das hatte ich mir auch erst überlegt, aber beim std::vector ist garantiert, dass der Speicher hintereinander liegt, was beim std::string nicht garantiert ist. Letztendlich geht es aber dann fast schon in die Richtung Mikro Optimierung und ich find den std::vector nach wie vor passender. Denn der Verwendungszweck entspricht exakt seiner Funktion.

[314159265358979]

sdfsdfsdf schrieb:

was beim std::string nicht garantiert ist

Das wäre mir neu. Zeig mir die Stelle aus dem Standard.

[sdfsdfsdf]

Tuxist: Ich habe dir genug Argumente genannt. Wenn du meinst, dass du es so machen willst, wie du hier gezeigt hast, dann mach es eben so.

314159265358979 schrieb:

sdfsdfsdf schrieb:

was beim std::string nicht garantiert ist

Das wäre mir neu. Zeig mir die Stelle aus dem Standard.

Es gibt diese Stelle sogesehen nicht, da im Standard nicht geschrieben wird, dass der Speicher zusammenhängend sein muss. Ganz anders beim std::vector, wo dies explizit verlangt und somit garantiert ist.

Fakt ist natürlich, dass viele Implementationen es so gelöst haben, dass der Speicher zusammenhängend ist. Doch eine Garantie gibt es nicht und je nach Plattform/Compiler kann man damit dann doch auf die Schnauze fallen. Insofenr ist man da mit std::vector gut bedient und immer auf der sicheren Seite.

Such bei Google einfach mal nach "std::string contigous".

[Tuxist]

sdfsdfsdf:
Deine Argumente sind nicht unbedingt falsch aber, dieses Bashing C vs C++ Grabenkriege finde ich anstregend. Ich habe mich ganz bewusst für eine manuelle Speicherverwaltung entschieden. Und gleich beleidigend zu werden halte für ich keine gute Option. Und es ist natürlich sicherer die C++ Funktionen zu verwenden aber das Debugging erleichtert es nicht unbedingt.

Es gibt für alles ein für und wieder. Und eine Tatsache kann man nicht von tisch Wischen C++ ist ein um die Objektorientierung und paar Annehmlichkeiten erweitertes C. Was besonders in den Compilern merken, dar läuft es meistens so ab C++ -> C -> Asm. Nun kann man in bestimmten Situation besonders wenn es darum Leistung zu optimieren einen schritt weglassen.

Dieser schritt ist auch nur logisch dar man C Funktionen auch in C++ verwenden kann. Ich weiß C99 und der alte C++ Standart sind ein Problem. Und gewisse C++ Funktionen werden direkt in ASM gewandelt aber im großen ganzen ist es so.

Wichtig ist es einfach auch zu wissen was grob im Background passiert.

[314159265358979]

Tuxist schrieb:

würde gehen aber das ding muss auch wieder kleiner werden

Na und? Dann mach ihn halt kleiner.

Tuxist schrieb:

wenn ich ein String nehme kann ich keinen memmove oder ähnliches machen beim parsen der Daten

Brauchst du auch nicht.

Tuxist schrieb:

das würde bedeuten das ist mit find und substr arbeiten müsste was sehr viel last erzeugt

Das liegt nicht am std::string sondern an deiner beschissenen Methode das Zeug zu parsen.

Tuxist schrieb:

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

Na und?

Tuxist schrieb:

Das hat schon einen Grund

Ja, wiederverwendung von altem Code. Das hat aber nichts damit zu tun, ob nun C oder C++ flotter ist.

Tuxist schrieb:

zu mal der code eh c clastig.. pthread.. sockets.. fork.. .

Nur weil du eine C-API benutzt, muss dein Code nicht C-ig sein.

Tuxist schrieb:

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

Was für ne unglaublich dumme Aussage. Tut man doch. Und die Nachteile darfst du mir jetzt ruhig nennen. Ich wette, das Problem bist wieder du.

Tuxist schrieb:

schon mal doom3 quellcode angesehen ?

Ja, und weiter?

Tuxist schrieb:

da wirst du das gleiche festellen.

Was werde ich feststellen?

Tuxist schrieb:

oder in tinyxml ?

Was ist denn damit? Klär mich auf, du Intelligenzbestie.

[314159265358979]

Tuxist schrieb:

Deine Argumente sind nicht unbedingt falsch

Nun gib halt zu, dass du Unrecht hast, du Pfeife.

Tuxist schrieb:

dieses Bashing C vs C++ Grabenkriege finde ich anstregend.

Wir auch. Deine schlecht verständlichen Posts übrigens auch.

Tuxist schrieb:

Ich habe mich ganz bewusst für eine manuelle Speicherverwaltung entschieden.

Automatische Speicherverwaltung hat keinen Overhead.

Tuxist schrieb:

Und gleich beleidigend zu werden halte für ich keine gute Option.

Bei so viel Ignoranz, Sturheit, Unwissenheit und dem nicht-vorhandensein von Lernfähigkeit hilft halt nichts mehr.

Tuxist schrieb:

Und es ist natürlich sicherer die C++ Funktionen zu verwenden aber das Debugging erleichtert es nicht unbedingt.

Lern halt, deinen Debugger zu benutzen, du Wurst. Wenn du die C++-Klassen verwenden würdest, bräuchtest du ihn auch gar nicht so oft.

Tuxist schrieb:

Und eine Tatsache kann man nicht von tisch Wischen C++ ist ein um die Objektorientierung und paar Annehmlichkeiten erweitertes

Falsch. C++ war das einmal, ist aber mittlerweile zu einem selbstständigen Lebewesen mutiert.

Tuxist schrieb:

Was besonders in den Compilern merken, dar läuft es meistens so ab C++ -> C -> Asm.

Mit Sicherheit nicht.

Tuxist schrieb:

Nun kann man in bestimmten Situation besonders wenn es darum Leistung zu optimieren einen schritt weglassen.

Aber nur, wenn es Sinn ergibt. Und das tut's in deinem Fall nicht.

Tuxist schrieb:

Wichtig ist es einfach auch zu wissen was grob im Background passiert.

Und genau da liegt dein Problem - du hast keine Ahnung von nichts.