Dateiendung aus argv[] parsen
-
Meine Güte, wo hast du denn deine Informationen her? Internettutorials? 15 Jahre alte Bücher? Hier ist eine gute Referenz:
Und so kann man das machen:
#include <string> #include <iostream> #include <vector> using namespace std; int main(int argc, char *argv[]) { vector<string> parameters(argv, argv+argc); for(int i=0; i<argc; ++i) cout << "Der " << i+1 << ". Parameter ist: " << parameters[i] << '\n'; if (argc > 1) { cout << "Analysiere " << parameters[1] << "...\n"; size_t dot_position = parameters[1].rfind('.'); if (dot_position != string::npos) { cout << "Endung gefunden: "; string suffix = parameters[1].substr(dot_position); cout << suffix << '\n'; } else cout << "Parameter enthält keine Punkt\n"; } else cout << "Nicht genügend Parameter\n"; }
-
Ne, aber fast:
ca. 15 Jahre alte Internettutorials. *g*
Ich bin Anfänger, nu mach mich doch nicht gleich runter.
Mal ne Frage, hast du den Code getestet?
Wenn nicht, bitte ich dich darum.Mein Compiler wirft 3 Fehler aus und kompiliert nicht.
Bei allen cout Befehlen, in denen parameters[] vorkommt (wozu auch der String suffix gehört) wird folgender Fehler ausgegeben:left expresion must be integral
left operand type is 'std::ostream (value)'
right operand type is 'std::basic_string<char...Wenn ich den cout Befehl ersetze durch:
printf("Der %d. Parameter ist: %s\n",i,parameters[ i ]);bin ich wieder soweit wie am Anfang.
Es wird fehlerfrei kompiliert, Absturz mit Ausgabe der Prozessorregister und der Meldung:
The instruction at 0x0040863f referenced memory at 0x02000002.
The memory could not be read.Die mem Adresse ist aber nicht immer dieselbe und manchmal kommt auch die Meldung
...could not be written.
-
Hui schrieb:
ca. 15 Jahre alte Internettutorials. *g*
Du nutzt nicht zufällig auch den Compiler, der dir da empfohlen wurde?
-
Ich nutze Open Watcom v.1.9 (Jun. 2010).
Zuvor hatte ich auch 2 andere Compiler versucht, aber wenn man als Anfänger gleich massenhaft mit Compiler-Fehlermeldungen bombardiert wird, die nichts mit mit dem C-Quelltext zu tun haben und man gezwungen wird, erst stundenlang englischsprachige Manuals zu studieren, um es dann doch nicht hinzukriegen, dann hat man schnell die Schnauze voll von dem Rotz.
Daß ein Compiler nach der Installation auch funktioniert scheint "zuviel verlangt". *g*Open watcom war hier ne Ausnahme und reicht mir bis jetzt für meine Zwecke.
Willst du mir sagen, daß es an meinem Compiler liegt?
Deswegen wäre es mir lieb, jemand bestätigt, daß das gepostete Code läuft.
-
Hui schrieb:
Willst du mir sagen, daß es an meinem Compiler liegt?
Deswegen wäre es mir lieb, jemand bestätigt, daß das gepostete Code läuft.Der Code läuft (getestet mit Visual Studio 10). Du kannst dir die Express Edition von Visual Studio 10 kostenlos bei Microsoft runterladen (achte darauf, dass du die C++ Version erwischst und nicht die für VB oder C#). Die IDE ist sehr gut und der Compiler auch. Das läuft normal auch out-of-the-box
-
Der Quelltext von Sepp lässt sich auch mit dem gcc(g++) und dem dmc mit STLport problemlos übersetzen.
MfG f.-th.
-
Was will der Beitragsersteller C oder C++?
Das muss dem Compiler mitgeteilt werden.
-
Hmm, wenn man es ultra-streng sieht, muss man noch ostream für den Operator << einbinden. Vielleicht macht das dein Compiler nicht indirekt durch iostream. Das printf nicht funktioniert ist kein Wunder, deshalb benutzt man es ja auch nicht in C++: Es kommt nicht mit komplexen Datentypen zurecht.
edit: Und du hast aber nicht string wieder durch string.h ersetzt? Dazu würde die Fehlermeldung nämlich auch passen.
-
Hui schrieb:
int main(int argc, char **argv) { char *zip; char *endung; if(argc==2) { endung=argv[1]; endung=strstr(endung,zip); printf("%s\n",endung); ...Ich will abhängig von der Endung bestimmten Code ausführen und nicht einfach die Endung ausgeben.
int main(int argc, char **argv) { if( argc>1 && strchr(argv[1],'.') && !strcmp(strrchr(argv[1],'.'),".zip") ) { /* hier kannst du jetzt was tun */ } ... return 0; }
-
f.-th. schrieb:
Was will der Beitragsersteller C oder C++?
Das muss dem Compiler mitgeteilt werden.Ich weiß ja nicht, wie das bei anderen Compilern ist, aber meinem teile ich das mit durch die Dateiendung .c oder .cpp.
#include <string> oder #include <iostream> (oder beides) läßt sich in C gar nicht verwenden. Jedenfalls bei meinem Compiler.@SeppJ
Ich bin der Meinung, daß ich es sogar probiert habe, ostream zu includen. Ich versuchs aber nochmal.
Alles was ich bisher gelesen ist, daß man wenns geht den std Namensraum vermeiden soll und wenns nicht geht z.B lieber schreiben soll:using std::cout;anstatt
using namespace std;Gilt das nur für c?
Die Syntax von cout ist ja einfacher als printf. Also wird mir der "Umstieg" nicht schwerfallen.
STRING.H geht gar nicht, weder in C noch in C++.
Ergebnis: Lauter "undefinierte symbols".Den Code von Wutz muss ich noch probieren.
Vielen Dank auch für den Tipp mit dem Visual C++. Ich dachte es gebe unter den kommerziellen nur von Borland ne kostenlose Version.
Wider Erwarten hat sogar die Installation und das Kompilieren auf Anhieb geklappt
Nachteil ist leider, daß der Code wie ich las erst ab Win XP SP 2 läuft.
Ab und zu brauch ich auch 16bit Code und welchen der z.B. auf Win NT läuft.
Aber zum testen auf jedenfall sinnvoll.
-
Hui schrieb:
[...viel Stuss ('tschuldigung, aber wenn ich es höflich ausdrücke, geht der Sinn verloren)...]
Ich bin mir sehr sicher, du machst beim Compilieren was falsch oder hast selbstständig was geändert, was den Fehler verursacht oder du benutzt Compiler aus Vorstandardzeiten. Der Code den ich oben gezeigt habe sollte überall funktionieren, ostream hin oder her. Da dein Beitrag zeigt, dass du viele (sehr) falsche Vorstellungen hast über das was du tust, bin ich daher ziemlich sicher, dass du irgendwo etwas aus Unkenntnis heraus falsch machst.
edit: Noch was konstruktives: Ich bin mal so großzügig, auf den Compiler zu tippen, da es mit VS bei dir auch funktioniert. Wenn du einen 16-Bit Compiler suchst, ist das schon ziemlich schwer, einen halbwegs standardkonformen zu finden. Du könntest mal Open Watcom probieren. Der ist zwar auch nicht berühmt für seine strikte Befolgung des Standards, aber er wird immerhin noch weiter entwickelt, vielleicht ist es besser geworden.
edit2: Ach, nutzt du schon. Tja, ist wohl nicht standardkonform genug
.
edit3: Und nachdem ich ihn mir gerade mal besorgt habe, kann ich deine Probleme damit nachvollziehen. Der Compiler bringt zwar eine Klasse String (mit großem S mit), die die Operatoren definiert hat, diese wiederum hat aber ganz andere Memberfunktionen, so das find & Co nicht mehr gehen
-
*lol* "viel Stuss"?
So viel hab ich ja gar nicht geschrieben.Gut OK, das mit ostream einbinden war sicherlisch "Stuss". Ich hatte in dem Moment nicht dran gedacht, daß cout ja teilweise funktionierte und somit auch der Operator <<. (was ich zuvor aber schrieb)
Ursache war der Stuss, den du geschrieben hast, daß es am Operator liegt und man ostrem einbinden müsse.Du schreibst, wenn du es "höflich" schreibst ginge der Sinn verloren. Welcher Sinn?
Stattdessen pauschal alles als "Stuss" abzutun hat also "Sinn"?
Das Mindeste wäre zu schreiben, was genau daran "Stuss" ist. (Und schön wäre es wenn du es begründest)Da du beides nicht machst, ist dein Post absulut sinnfrei.
Außer dass er den Eindruck hinterläßt, beileidigend zu sein.
Oder sollte das der Sinn sein? (Dann steh ich drüber.)Wahrscheinlich hast du mehr Ahnung von C als ich, dafür aber ne Leseschwäche.
1. ich schrieb, ich benutze WatCom (was du ja noch selbst herausgefunden hast)
2. ich schrieb, daß cout nur bei 3 bestimmten codezeilen nicht funktionierte, was dir hätet sagen müssen daß es direkt am Datentyp von argv liegen muss und nicht am Operator "<<"
Was mich aber nicht veranlasst, dich dafür zu beleidigen.
Danke für die Mühe, die du dir gemacht hast und so den Fehler nachvollzogen hast.
-
Ja, nu, wenn alles falsch oder wirr ist, dann ist eine Einzelkritik eben schwer. Der Sinn, ein so provozierendes Wort wie "Stuss" zu verwenden, war es, dich zu provozieren, damit du mal ein bisschen über deine Aussagen nachdenkst. Es hat hervorragend funktioniert. Das Wort war eine gut Wahl.
Gravierender Fehler: C und C++ sind komplett andere Sprachen. Daraus folgen bei dir komische Aussagen:
#include <string> oder #include <iostream> (oder beides) läßt sich in C gar nicht verwenden.
Sag bloß. Zumal du hier im C++ Forum fragst, die Leute am Anfang aber gar nicht erkennen konnten, ob du nicht C meinst. Du machst zwar einen Smiley an deine Aussage, aber nach dem was du vorher gesagt hast, ist nicht erkennbar, ob du das ironisch oder ernst gemeint hast.
[...Namensräume...]
Gilt das nur für c?
Du verstehst auch nicht wo drauf andere hinaus wollen:
STRING.H geht gar nicht, weder in C noch in C++.
Ergebnis: Lauter "undefinierte symbols".Es sollte ja auch nicht gehen!
...Namensräume...
Entweder haben die, die dir das erzählt haben, Stuss geredet oder du hast sie nicht richtig verstanden.
Gut OK, das mit ostream einbinden war sicherlisch "Stuss".
Nein, das war eine der wenigen Aussagen die kein Stuss waren, das war aber bloß eine Verzweiflungstat mit extrem geringen Erfolgsaussichten und es überrascht mich nicht, dass sie nicht funktioniert hat.
ich schrieb, ich benutze WatCom (was du ja noch selbst herausgefunden hast)
Ich les aber nicht jede Aussage von jedem ganz genau in so einem langen Thread.
ich schrieb, daß cout nur bei 3 bestimmten codezeilen nicht funktionierte, was dir hätet sagen müssen daß es direkt am Datentyp von argv liegen muss und nicht am Operator "<<"
So? Erklär mal. Denn es liegt da dran, dass es den Operator nicht für std::string gibt. Der sollte zwar in string stehen, aber bei Aussagen wie diesen:
Bei allen cout Befehlen, in denen parameters[] vorkommt (wozu auch der String suffix gehört) wird folgender Fehler ausgegeben:
Da traue ich dem Übermittler der Fehlermeldungen nicht.
...Fehlverständnis des Wortes Stuss und auffassen eines solchen Wortes als Beleidigung...
Siehe oben:
SeppJ schrieb:
Du verstehst auch nicht wo drauf andere hinaus wollen
Ok, so viel hast du wirklich nicht geschrieben, aber praktisch alles an deinem Beitrag war irgendwie falsch, wirr oder ungenau
Ich bin aber auch nicht der C++-Stilführer, ich werde jetzt nicht 5 Seiten über Namensräume und die Unterschiede zwischen C und C++ philosophieren, nur weil es dich eventuell interessieren könnte. Wenn du konkrete Fragen hast, dann stell sie noch einmal explizit.
-
Vielleicht hast du auch nur nicht verstanden, worauf ich hinaus wollte.
Ich hatte das auf verschiedenen Seiten gelesen, daß man den std Namensraum vermeiden soll, um Konflikte zu vermeiden und es nicht standardmäßig in jedem Programm verwenden sollte.Nun erfahr ich, daß printf völlig out ist und sowieso nicht mehr verwendet wird.
Und dein code vermeidet ja nicht "namespace std".
Deswegen meine Frage, da man es offensichtlich in C++ nicht vermeiden soll, ob dies nur bei C sinvoll war.Über die Art Sachen zu programmieren gibts immer verschiedene Ansichten. Deswegen muss die eine nicht gleich "falsch" sein.
Daß C++ was "völlig" anderes sei als C ist mir neu
Ich Idiot dachte, daß es auf C basiert, dazu kompatibel ist und eine Befehlserweiterung darstellt.
Den Sinn der Frage, was von beiden ich nun verwenden will, hab ich tatsächlich nicht so richtig verstanden.
Ich schrieb, was mein Programm können soll. Wenn dazu nun Befehle nötig sind, die nur in C++ funktionieren, benutze ich C++, das ist doch wohl klar?
Ansonsten ist es mir schnurzegal, solange das Programm funktioniert.Ach, es gibt zwar den Operator "<<" aber nicht für "std::string"? Hatte sich bei dem ostream includen noch anders angehört.
Zitat:
"Da traue ich dem Übermittler der Fehlermeldungen nicht. "
Ich nehm an, das tust du erst, nachdem es selbst mit Open Watcom probiert hast?
Denn an dem, was ich über die 3 Fehler schrieb, ist ja nichts falsches.
-
C++ ist mittlerweile quasi eine komplett eigene Sprache. Exceptions, Klassen, Templates, ... Man programmiert dadurch völlig anders als in C.
-
Hui schrieb:
Nun erfahr ich, daß printf völlig out ist und sowieso nicht mehr verwendet wird.
Und dein code vermeidet ja nicht "namespace std".
Deswegen meine Frage, da man es offensichtlich in C++ nicht vermeiden soll, ob dies nur bei C sinvoll war.Diese Frage macht keinen Sinn! Das sind zwei verschiedene Sprachen! In C gibt es das gar nicht! Und printf funktioniert in C++ nicht wirklich wie sich Anfänger das vorstellen. Ich erinnere dich an deinen erbärmlich gescheiterten Versuch, die Strings mittels printf auszugeben.
Und das mit den Namespaces hast du schlicht falsch erklärt bekommen oder falsch verstanden.
Über die Art Sachen zu programmieren gibts immer verschiedene Ansichten. Deswegen muss die eine nicht gleich "falsch" sein.
Doch, es gibt falsche Ansichten. Und ich kann durchaus differenzieren zwischen meinen eigenen Ansichten, anderen Ansichten und falschen Ansichten.
Daß C++ was "völlig" anderes sei als C ist mir neu
Ich Idiot dachte, daß es auf C basiert, dazu kompatibel ist und eine Befehlserweiterung darstellt.Da bist du aber ziemlich alleine. Technisch gesehen mag das stimmen, aber vergleich mein Programm mit deinem ursprünglichen C Programm. Besteht da irgendeine Ähnlichkeit, außer int main und der Bedeutung der Sonderzeichen? Und meines ist noch nicht mal richtig durchgestyltes C++, sondern mit Absicht für jemanden der von C kommt verständlich programmiert.
Den Sinn der Frage, was von beiden ich nun verwenden will, hab ich tatsächlich nicht so richtig verstanden.
Ich schrieb, was mein Programm können soll. Wenn dazu nun Befehle nötig sind, die nur in C++ funktionieren, benutze ich C++, das ist doch wohl klar?
Ansonsten ist es mir schnurzegal, solange das Programm funktioniert.Inwiefern ist das keine wichtige Frage? Nochmal: Es sind zwei komplett unterschiedliche Sprachen! So unterschiedlich wie C++ und C# oder C++ und Java!. Namensähnlichkeit, Syntaxähnlichkeit und eine gewisse Abwärtskompatibilitat ist doch egal! Du kannst kein C++-Programm auf einem C Compielr übersetzen! Und ein C Programm geht mit Würgen durch den C++-Compiler.Vielleicht würde der OpenWatcom ein standardkonformes C-Programm schlucken. C ist eine sehr viel einfachere Sprache und viel länger etabliert. Es ist sehr gut möglich, dass der OpenWatcom 100% ANSI C konform ist. Aber du hast hier im C++-Forum gefragt und entsprechende Antworten bekommen. Das gleiche Programm kann man in C schreiben, aber es sähe ganz anders aus. C++ ist nirgends nötig, um etwas überhaupt erreichen zu können. Jede (nicht-esoterische) Computersprache kann alles erreichen. Die Wahl der Sprache ist die Wahl der Herangehensweise. Und das ist eine ungeheuer wichtige Entscheidung.
Und ich finde es erschrecken, dass du das nicht weißt oder nicht erkennst, aber hier auftrittst, als wärst du der einzige Überchecker auf der Welt und die anderen alle doof. Schon mal überlegt, ob alle anderen vielleicht Recht haben und man als einziger falsch liegen könnte?Ach, es gibt zwar den Operator "<<" aber nicht für "std::string"? Hatte sich bei dem ostream includen noch anders angehört.
Zitat:
"Da traue ich dem Übermittler der Fehlermeldungen nicht. "
Ich nehm an, das tust du erst, nachdem es selbst mit Open Watcom probiert hast?
Denn an dem, was ich über die 3 Fehler schrieb, ist ja nichts falsches.Ich schreibe nochmal deine Fehlermeldung:
Bei allen cout Befehlen, in denen parameters[] vorkommt (wozu auch der String suffix gehört) wird folgender Fehler ausgegeben:
Das ist doch verquierlter Unsinn. Ich gehe mal gar nicht da drauf ein, dass cout kein Befehl ist, das kann ein ANfänger leicht missverstehen. Aber suffix als ein parameters[i] zu sehen ist einfach so wirr, dass derjenige der den Satz geschreiben hat, nicht als zuverlässige Quelle angesehen werden kann. Leugnest du das oder verstehst du gar nicht, was mich an dem Satz stört?
-
Ich erinnere dich an deinen erbärmlich gescheiterten Versuch, die Strings mittels printf auszugeben.
Hier kommt wieder deine Leseschwäche zum tragen.
Die Ausgabe der Strings funktionierte (was aber nicht das Ziel war), nur der Vergleich der Strings scheiterte.Doch, es gibt falsche Ansichten.
Naklar gibts die. Ich hab auch nicht das Gegenteil behauptet.
Du willst also damit sagen, es ist falsch, "using std::cout;" zu schreiben, statt den gesamten std Namensraum freizugeben? (denn darauf bezog sich meine von dir zitierte Aussage)
Komisch, das Programm läuft trotzdem. Kann so falsch also nicht sein.vergleich mein Programm mit deinem ursprünglichen C Programm. Besteht da irgendeine Ähnlichkeit
Ist doch kein Wunder, wenn man die Befehle durch andere mit anderer Syntax ersetzt. Ich weiß nicht, was du damit sagen willst...
Genau dasselbe könnte man auch unter C machen und hätte ein "völlig anderes" Programm.C++ ist nirgends nötig, um etwas überhaupt erreichen zu können.
Deine Leseschwäche ist wirklich sehr stark ausgeprägt. Auch das hab ich nicht behauptet. (lies meine Aussage einfach nochmal)
Jede (nicht-esoterische) Computersprache kann alles erreichen.
Das ist ja großartig. Ich wollte schon immer mal mit JavaScript Dateien erstellen.
Und ich finde es erschrecken, dass du das nicht weißt oder nicht erkennst, aber hier auftrittst, als wärst du der einzige Überchecker auf der Welt und die anderen alle doof.
Und ich finde deine Leseschwäche erschreckend.
Und daß du mir sachen andichtest, die ich nie gesagt hab.
Ich geh davon aus, daß 90% der Mitglieder des Forums bezüglich C/C++ mehr wissen als ich, was dich mit einschließt.
Ich hab mich doch schon selbst als Idiot bezeichnet. Was soll ich denn noch tun? *lol*Ich gehe mal gar nicht da drauf ein, dass cout kein Befehl ist, das kann ein ANfänger leicht missverstehen. Aber suffix als ein parameters[i] zu sehen ist einfach so wirr, dass derjenige der den Satz geschreiben hat, nicht als zuverlässige Quelle angesehen werden kann. Leugnest du das oder verstehst du gar nicht, was mich an dem Satz stört?
"cout" ist Teil des Befehls zur Bildschirmausgabe. Und nichts anderes wollt ich damit sagen. Daß du es anders ausdrücken würdest, dafür kann ich nichts.
Daß dich immer irgendwas an irgendeiner Formulierung stört, kann ich verstehen. Der Grund ist einfach deine Korinthenkacker Art.
Denn was ich meinte, ist auch für dich ersichtlich.
suffix wurde das Ergebnis einer Stringoperation zugewiesen, an der parameters[i] beteiligt ist. Deshalb erzeugt der Openwatcom Compiler ne Fehlermeldung. Mit jedem anderen String (statt parameters[i]) funktioniert es.
Deshalb ging ich davon aus, daß argv nicht exakt genauso wie ein String behandelt wird, oder der Datentyp sich unterscheidet.
Du meinst ja, es liegt am Operator <<.
in der Zeilestring suffix = parameters[1].substr(dot_position);kommt aber kein "<<" vor.
Ich vergleich das mal so:
wenn 0x9 - 0x1 funktioniert, aber 0xA - 0x1 nicht, kommt sicherlich auch niemand auf die Idee zu sagen, "Der Operator Minus ist für A nicht definiert"
-
Du willst also damit sagen, es ist falsch, "using std::cout;" zu schreiben, statt den gesamten std Namensraum freizugeben?
Nein, er will sagen, dass ein using generell böse ist, wenns in einem Header steht! Das entfernt den Namensraum von einem ("using std::cout") oder allen ("using namespace std") Objekten/Funktionen/Klassen/... aus dem Namensraum, nicht nur im Header sondern für alle die den Header einbinden! Und DAS ist richtig böse (ich werd jetzt nicht über Sinn und Unsinn von Namensräumen philosophieren, lies dich mal ein, für was die gedacht sind...).
In einer .cpp ist ein using nicht so tragisch, man sollte aber natürlich wissen, was man macht (eine eigene Klasse "string" + using namespace std werden sich in manchen Konstellationen auch nicht SO gut vertragen).Komisch, das Programm läuft trotzdem. Kann so falsch also nicht sein.
Schön. Wenn du mit dem using-Zeug nicht aufpasst, wirst du vllt. irgendwann mal richtig böse Fehlermeldungen beim Kompilieren bekommen - sind nicht so leicht zu debuggen...
Jede (nicht-esoterische) Computersprache kann alles erreichen.
Das ist ja großartig. Ich wollte schon immer mal mit JavaScript Dateien erstellen.
http://www.c-point.com/JavaScript/articles/file_access_with_JavaScript.htm
"cout" ist Teil des Befehls zur Bildschirmausgabe.
Nö, nö, nö...
cout is an object of class ostream that represents the standard output stream.
Aus http://www.cplusplus.com/reference/iostream/cout/
cout ist kein "Befehl" sondern ein "Objekt". Mag für den Laien vllt. wurscht sein, als Programmierer sollte man aber soweit differenzieren und versuchen, die richtigen Begriffe zu verwenden.
-
@Hui: Das ist genau das was ich an deiner Einstellung mittels
Und ich finde es erschrecken, dass du das nicht weißt oder nicht erkennst, aber hier auftrittst, als wärst du der einzige Überchecker auf der Welt und die anderen alle doof.
kritisiere. Du kommst hier mit irgendwelchen komischen Behauptungen an, die aus extremer Anfängerperspektive vielleicht so aussehen und behauptest, dass das so wäre. Du weißt so wenig über die Sprache, dass du noch nicht einmal erkennst, was die wesentlichen Unterschiede zwischen dem C und dem C++ Programm sind und das bloß für eine andere Schreibweise mit anderen Befehlen hältst. Du hast irgendwo mal was von using namespace wäre böse gelesen, hast aber nicht verstanden warum und bringst jetzt total unpassende Argumente. Du attestiert anderen Leseschwäche, merkst aber nicht einmal, dass sie sich auf deinen zweiten Versuch bezogen, was durch die Wortwahl eindeutig wäre, wenn du irgendetwas über Zeichenketten in C und C++ wüsstest. Du philosophierst hier über Operatoren und Methoden rum, ohne irgendeine Ahnung davon zu haben wovon du sprichst, was für jeden der das liest sofort klar ist.
Wenn man absolut keine Ahnung hat und man zu gibt dass man dies weiß, dann sollte man vielleicht nicht versuchen auch noch gegen jemanden zu argumentieren der einem sagt dass man Unrecht hat. Du verzapfst hier immer mehr Blödsinn und reitest dich immer weiter rein, bloß weil du dich in deiner Ehre angegriffen fühlst. Huh! Jemand im Internet behauptet ich hätte keine Ahnung von dem Thema in dem ich keine Ahnung habe! Das muss mit aller Härte beantwortet werden!
-
Don't stop the party.
