Nur Zahlen und Buchstaben ausgeben

[;fricky]

^^warum so kompliziert? ihr c++-freaks habt den sinn für einfachheit scheinbar völlig verloren. tntnet war schon auf dem richtigen weg. probier mal das:

#include <iostream>
using namespace std;

int main()
{
    char in[256];
    cin.getline (in, sizeof(in));
    for (char *s = in; *s; s++)   // <--- kann man natürlich auch als separate funktion schreiben
        if (isalnum(*s))
            putchar (*s);
}

[volkard]

;fricky schrieb:

^^warum so kompliziert? ihr c++-freaks habt den sinn für einfachheit scheinbar völlig verloren.

Vielleicht ist es die Freude am Schmerzempfinden.
Aber Du hättest string nehmen dürfen, um nicht auf 256 festgelegt zu sein und die Ausgabe mit cout<<*s erledigen dürfen.

[;fricky]

volkard schrieb:

;fricky schrieb:

^^warum so kompliziert? ihr c++-freaks habt den sinn für einfachheit scheinbar völlig verloren.

Vielleicht ist es die Freude am Schmerzempfinden.

vielleicht. einen leichten hang zum masochismus werden einige c++ programmierer wohl haben. anders könnte ich mir z.b. nicht erklären, warum tntnet diese malloc/memcpy/free-orgie gebastelt hat.

volkard schrieb:

Aber Du hättest string nehmen dürfen, um nicht auf 256 festgelegt zu sein und die Ausgabe mit cout<<*s erledigen dürfen.

naja, und 'nen übermässigen generalisierungs-trieb haben sie auch. wenn 256 chars nicht reichen, mach einfach 2048 daraus oder was passt. aber das wird den cpp-fan nicht befriedigen, denn für ihn muss es für theoretisch unendlich lange eingaben funktionieren. <-- sowas ist in der realität nur kontraproduktiv.

[volkard]

;fricky schrieb:

naja, und 'nen übermässigen generalisierungs-trieb haben sie auch. wenn 256 chars nicht reichen, mach einfach 2048 daraus oder was passt. aber das wird den cpp-fan nicht befriedigen, denn für ihn muss es für theoretisch unendlich lange eingaben funktionieren. <-- sowas ist in der realität nur kontraproduktiv.

Es gibt auch PCs. Vermutlich ist das Programm sogar für dein Einsatz auf PCs geplant. Also warum nicht string? Es ist doch fertig da.

[;fricky]

volkard schrieb:

Vermutlich ist das Programm sogar für dein Einsatz auf PCs geplant. Also warum nicht string? Es ist doch fertig da.

ja, der OP hat einen 'AnsiString', das ist eine cpp-klasse von borland, die hat auch 'ne 'c_str' funktion, damit kann er locker die char*-variante benutzen. das mit der eingabe war ja auch nur zur demo.

[tntnet]

;fricky schrieb:

vielleicht. einen leichten hang zum masochismus werden einige c++ programmierer wohl haben. anders könnte ich mir z.b. nicht erklären, warum tntnet diese malloc/memcpy/free-orgie gebastelt hat.

Offensichtlich muss ich meine malloc/memcpy/free-orgie noch erläutern.

Aber zunächst einmal, das Beispiel mit char[256] ist, wie Volkard bereits gesagt hat, unvollständig, da hier eine Längenbegrenzung geschaffen wird.

Also fricky: Du meinst doch immer, dass C++ so schlecht ist. Also verzichte ich in meinem Beispiel auf C++ und schreibe das ganze in klassischen C. Dafür muss ich natürlich einen Puffer alloziieren, was mit malloc geschieht. Und wenn der Puffer nicht gross genug ist, muss ich einen grösseren alloziiern, den bisherigen Inhalt rein kopieren und den alten Speicher frei geben.

Oder hast Du da eine andere Idee, ohne C++ Mittel und ohne Längenbegrenzung (na ja - Systembendingte Längenbegrenzung haben wir natürlich, aber das ist ein anderes Thema)?

Ich verwende gerne C++, da ich genau diesen Algorithmus unter Verwendung von std::string bekomme. Ich bekomme mit einfachen Mitteln ein kurzes knackiges Programm hin, welches einfach so funktioniert, wie es soll.

Im übrigen ist mein C Beispiel auch noch fehlerhaft, da es nicht prüft, ob der Speicher auch erfolgreich alloziiert wurde. Auch darum brauche ich mich mit C++ nicht zu kümmern.

Und zu Deiner Argumentation, dass man den Puffer einfach grösser machen kann: damit verschwendest Du natürlich Platz und hast dennoch eine Begrenzung. Im C++-Beispiel liegt die Begrenzung im Gigabyte-Bereich ohne dass Gigabyteweise Speicher reserviert werden muss.

Eine manuelle Eingabe ist sicher ein schlechtes Beispiel. Hier würde es nicht wirklich allzuviel schaden, den Puffer einfach gross genug zu machen. Oder halt - was ist, wenn ich damit eine Datei filtern will, also die Daten über eine Umleitung der Standardeingabe aus einer Datei lese? Dann kommen schnell 2kB zusammen.

Ein Programm muss möglicherweise Eingaben von ausserhalb verarbeiten. Und da hat man nicht immer Einfluss, was da so rein kommt. Was glaubst Du, wo ich die Url in meinem Tntnet sammele? Bestimmt nicht in einen festen Puffer. Auch wenn die Url in der Regel nicht länger als sagen wir mal 2kB ist. Dennoch muss ein Webserver in der lage sein, robust darauf zu reagieren, wenn beispielsweise ein Hacker mit langen Urls versucht Pufferüberläufe zu provozieren.

[;fricky]

tntnet schrieb:

Aber zunächst einmal, das Beispiel mit char[256] ist, wie Volkard bereits gesagt hat, unvollständig, da hier eine Längenbegrenzung geschaffen wird.

nö, denn es ging hier nur um das rauspflücken von buchstaben und zahlen. zur demonstration, wie man sowas z.b. machen kann, reichen 256 chars völlig aus. 10 oder so hätten's auch schon getan.

tntnet schrieb:

Also verzichte ich in meinem Beispiel auf C++ und schreibe das ganze in klassischen C. Dafür muss ich natürlich einen Puffer alloziieren, was mit malloc geschieht. Und wenn der Puffer nicht gross genug ist, muss ich einen grösseren alloziiern, den bisherigen Inhalt rein kopieren und den alten Speicher frei geben.

nö, du musst überhaupt nix allozieren. du wolltest mit deinem beispiel nur zeigen, dass man in C angeblich immer und immer wieder alles neu schreiben muss und dass einem dabei fehler passieren, um den vorteil der fertigen libraries von C++ hervorzuheben. dass es auch für C existierende libs gibt, um mit eingaben und strings variabler länge fertigzuwerden, hast du dabei bewusst unterschlagen.

tntnet schrieb:

Und zu Deiner Argumentation, dass man den Puffer einfach grösser machen kann: damit verschwendest Du natürlich Platz und hast dennoch eine Begrenzung.

niemand hindert dich, den buffer wiederzuverwenden. programme, die mit festen buffern arbeiten, sind in der regel performanter und kleiner. dynamische speicheranforderungen können fehlschlagen oder zwacken dem system speicher ab, der an anderer stelle plötzlich fehlen könnte. hat alles so seine vor- und nachteile.

tntnet schrieb:

Ein Programm muss möglicherweise Eingaben von ausserhalb verarbeiten. Und da hat man nicht immer Einfluss, was da so rein kommt. Was glaubst Du, wo ich die Url in meinem Tntnet sammele? Bestimmt nicht in einen festen Puffer. Auch wenn die Url in der Regel nicht länger als sagen wir mal 2kB ist. Dennoch muss ein Webserver in der lage sein, robust darauf zu reagieren, wenn beispielsweise ein Hacker mit langen Urls versucht Pufferüberläufe zu provozieren.

der webserver könnte einfach URLs länger als 2K ablehnen. genauso braucht er eine begrenzung, wieviele verbindungen er gleichzeitig bedienen kann. stattdessen hört sich's bei dir so an, als bräuchte ein hacker einfach nur ~100 verbindungen herzustellen und alle mit einigen GB langen URLs zu füttern, um das ganze system (nicht nur den webserver) lahmzulegen.

[independent read0r]

volkard schrieb:

Aber Du hättest string nehmen dürfen, um nicht auf 256
festgelegt zu sein und die Ausgabe mit cout<<*s erledigen dürfen.

.... und das Aussortieren der Zahlen und Buchstaben macht der Stream wie von Geisterhand vollautomatisch.

[volkard]

independent read0r schrieb:

volkard schrieb:

Aber Du hättest string nehmen dürfen, um nicht auf 256
festgelegt zu sein und die Ausgabe mit cout<<*s erledigen dürfen.

.... und das Aussortieren der Zahlen und Buchstaben macht der Stream wie von Geisterhand vollautomatisch.

da steht nicht, daß er aufs if verzichten sill.

[tntnet]

;fricky schrieb:

der webserver könnte einfach URLs länger als 2K ablehnen. genauso braucht er eine begrenzung, wieviele verbindungen er gleichzeitig bedienen kann. stattdessen hört sich's bei dir so an, als bräuchte ein hacker einfach nur ~100 verbindungen herzustellen und alle mit einigen GB langen URLs zu füttern, um das ganze system (nicht nur den webserver) lahmzulegen.

"Hört sich an"? Entschuldigung für meine ungenaue Ausdruckweise.
Probiere es aus. Versuche, tntnet lahmzulegen. Versuche, damit das ganze System lahmzulegen. Ich bin guter Dinge, dass Dir das nicht so einfach gelingen wird. Aber beschränke Dich nicht auf 100 Verbindungen. Du solltest viel mehr verwenden. Da gibt es schliesslich kein Array mit 100 Verbindungen und bei der 101. wird die Arbeit eingestellt.

Es liegt in der Natur von C++, dass es relativ einfach ist, robuste Programme zu schreiben. C++ bietet mir Features, die mich dabei unterstützen.

Natürlich kann ich mit andere Programmiersprachen wie beispielsweise C auch Bibliotheken schreiben, die mir die Arbeit abnehmen. Ich habe selbst mal einen dynamischen String in C geschrieben. Ich kenne aber keine Sprache, wo ich so einfache und robuste APIs designen kann, wie in C++. (Aber das mag ein meiner Unwissenheit und Naivität liegen.)

Ach verflucht - jetzt habe ich mich in eine Diskussion mit fricky eingelassen . Liebe Leser: ich bitte um Entschuldigung. Ich werde versuchen mich zurück zu halten.

[;fricky]

tntnet schrieb:

Ach verflucht - jetzt habe ich mich in eine Diskussion mit fricky eingelassen . Liebe Leser: ich bitte um Entschuldigung. Ich werde versuchen mich zurück zu halten.

keine angst, wir können das sofort beenden. ich hab nur eine letzte frage: was macht dein webserver, wenn er eine URL bekommt, die einfach kein ende nehmen will? der apache z.b. schluckt bis zu 4K, danach schickt er ein 413 'entity too large'. deiner saugt sich 'nen std::string oder vector voll, bis die kiste 'out of memory' geht, richtig?

[µngbd]

Es liegt in der Natur von C++, dass es relativ einfach ist, robuste Programme zu schreiben.

Und wieso erzählt volkard dann dauernd, wie viel wir armen Tölpel noch lernen müssen?

[;fricky]

µngbd schrieb:

Es liegt in der Natur von C++, dass es relativ einfach ist, robuste Programme zu schreiben.

Und wieso erzählt volkard dann dauernd, wie viel wir armen Tölpel noch lernen müssen?

vielleicht deshalb:

tntnet schrieb:

(Aber das mag ein meiner Unwissenheit und Naivität liegen.)

[asddadadaadaaa]

;fricky schrieb:

tntnet schrieb:

Ach verflucht - jetzt habe ich mich in eine Diskussion mit fricky eingelassen . Liebe Leser: ich bitte um Entschuldigung. Ich werde versuchen mich zurück zu halten.

keine angst, wir können das sofort beenden. ich hab nur eine letzte frage: was macht dein webserver, wenn er eine URL bekommt, die einfach kein ende nehmen will? der apache z.b. schluckt bis zu 4K, danach schickt er ein 413 'entity too large'. deiner saugt sich 'nen std::string oder vector voll, bis die kiste 'out of memory' geht, richtig?

Ich mag die Vorstellung

[;fricky]

asddadadaadaaa schrieb:

Ich mag die Vorstellung

ich auch. tntnet soll mal ne adresse posten, wo sein server läuft (seine webpräsenz läuft ja leider auf 'nem apachen unter debian). dann können wir ja mal 'ne 'denial of service' attacke durch aufbrauchen des speichers versuchen. *fg*

[tntnet]

;fricky schrieb:

tntnet schrieb:

Ach verflucht - jetzt habe ich mich in eine Diskussion mit fricky eingelassen . Liebe Leser: ich bitte um Entschuldigung. Ich werde versuchen mich zurück zu halten.

keine angst, wir können das sofort beenden. ich hab nur eine letzte frage: was macht dein webserver, wenn er eine URL bekommt, die einfach kein ende nehmen will? der apache z.b. schluckt bis zu 4K, danach schickt er ein 413 'entity too large'. deiner saugt sich 'nen std::string oder vector voll, bis die kiste 'out of memory' geht, richtig?

Falsch. Es gibt eine konfigurierbare maximale Request-Grösse. Wenn die Url (oder irgend etwas anderes im Request) diese Grösse überschreitet, antwortet tntnet mit dem HTTP-Fehler 413 (Request entity too large). Also fast so wie apache. Ausser dass die Grösse konfigurierbar ist und auch request header und body berücksichtigt werden. Apache ist halt in C geschrieben und da macht es offensichtlich zu viel Arbeit, die Grösse konfigurierbar zu machen .

µngbd schrieb:

Es liegt in der Natur von C++, dass es relativ einfach ist, robuste Programme zu schreiben.

Und wieso erzählt volkard dann dauernd, wie viel wir armen Tölpel noch lernen müssen?

Und noch was dazu: Es ist relativ einfach, wenn man C++ beherrscht. Das erfordert allerdings relativ viel Lernaufwand. So wie es relativ einfach ist, ein Flugzeug bei guten Wetter zu landen. Aber man muss halt erst mal fliegen lernen.

Jeder kann sich gerne einen tntnet installieren und selbst testen. Es ist sicher einfacher, einen Webserver über localhost zu überlasten, als über eine Internet-Leitung. Aber ich warne gleich vorweg: es ist relativ einfach tntnet zu installieren und Applikationen dafür zu schreiben .

[;fricky]

tntnet schrieb:

Es gibt eine konfigurierbare maximale Request-Grösse.

soso, wer war nochmal gegen irgendwelche begrenzungen?

tntnet schrieb:

Apache ist halt in C geschrieben und da macht es offensichtlich zu viel Arbeit, die Grösse konfigurierbar zu machen.

ja, in C ist vieles völlig unmöglich, config-files lesen und so geht überhaupt nicht, variablen gibts keine, alles total hartkodiert und statisch. man muss alles immer wieder von hand neu programmieren, libraries gibts nicht, einfach die absolute loser-sprache. pfui teufel! *grins*

tntnet schrieb:

Und noch was dazu: Es ist relativ einfach, wenn man C++ beherrscht. Das erfordert allerdings relativ viel Lernaufwand. So wie es relativ einfach ist, ein Flugzeug bei guten Wetter zu landen. Aber man muss halt erst mal fliegen lernen.

schon klar. und man ist unglaublich stolz darauf, zum erlauchten kreis der jetpiloten zu gehören, die auch mal 'ne bruchlandung überleben.

tntnet schrieb:

Jeder kann sich gerne einen tntnet installieren und selbst testen.

nenn doch mal eine internet-erreichbare webseite, die tntnet einsetzt. oder macht das keiner, weil niemand bock hat, webapplikationen vorher durch'n c++ compiler zu jagen und zu linken, oder weil tntnet nur unter linux läuft, oder weil sie angst vor laufzeitfehlern haben, die ihr system kompromittieren könnten, oder einfach nur, weil keiner einsieht, eine archaische, fehleranfällige sprache wie C++ für webapps zu benutzen, wo es doch schon lange viele ausgereifte, bewährte und sichere lösungen gibt?

[volkard]

tntnet schrieb:

Ach verflucht - jetzt habe ich mich in eine Diskussion mit fricky eingelassen . Liebe Leser: ich bitte um Entschuldigung. Ich werde versuchen mich zurück zu halten.

Tja, das haste nun davon. Er ist nichtmal den einfachsten Argumenten gegenüber zugänglich. Achte übrigens nicht auf die unregistrierten Begleittrolle, die ist er meistens selber, um den Eindruck eine Diskussion zu erwecken.

[;fricky]

volkard schrieb:

Achte übrigens nicht auf die unregistrierten Begleittrolle, die ist er meistens selber, um den Eindruck eine Diskussion zu erwecken.

hihi, du als moderator könntest doch z.b. anhand der ip-adressen erkennen, dass das nicht stimmt. ich versichere aufrichtig, dass ich nie diskussionen pushe, indem ich als mehrere unregs auftrete.

[tntnet]

;fricky schrieb:

tntnet schrieb:

Es gibt eine konfigurierbare maximale Request-Grösse.

soso, wer war nochmal gegen irgendwelche begrenzungen?

tntnet schrieb:

Apache ist halt in C geschrieben und da macht es offensichtlich zu viel Arbeit, die Grösse konfigurierbar zu machen.

ja, in C ist vieles völlig unmöglich, config-files lesen und so geht überhaupt nicht, variablen gibts keine, alles total hartkodiert und statisch. man muss alles immer wieder von hand neu programmieren, libraries gibts nicht, einfach die absolute loser-sprache. pfui teufel! *grins*

Du verstehst offensichtlich meine Sprache nicht. Ich habe geschrieben, dass es "offensichtlich zu viel Arbeit" macht und nicht, dass es völlig unmöglich sei. Aber vielleicht lernst Du ja mal, die Argumente aufmerksam zu lesen und Dich dann qualifiziert zu äussern.

Und irgendwie habe ich das Gefühl, Du versuchst zu erklären, dass tntnet schlecht ist, ohne dass Du bereit bist, das auch nur anzuschauen. Du gehst einfach davon aus, dass es schlecht sein muss. Da habe ich nun eigentlich keine Lust, mich da zu verteidigen.