Motivation bei Privatprojekten (Split aus Diamond of Death)
-
die datei bot.cpp finde ich nicht gut, da ist für jede fehlermeldung 2 x der string vorhanden
logger::warning("host missing in config file."); user_info("host missing in config file.");das is die hölle
-
Ja, dafür wollte ich mir noch was überlegen. Aber das ist nicht so schlimm, IMO.
-
dry schrieb:
die datei bot.cpp finde ich nicht gut, da ist für jede fehlermeldung 2 x der string vorhanden
logger::warning("host missing in config file."); user_info("host missing in config file.");das is die hölle
string pooling sollte der compiler können.
-
Irgendwie habt ihr mich nun motiviert, trotzdem weiterzumachen. Ich habe nun den Code etwas aufgeräumt und noch etwas Funktionalität hinzugefügt.
Nun zu meiner nächsten Designfrage (Plugin API). Die Plugins bekommen die Nachrichten von stdin und senden über stdout. Nun ist es aber so, dass wenn ein Plugin z.B. den Nickname ändern will, dass es dann nicht direkt die Antwort bekommt. Der Server könnte andere Antworten zuerst senden und danach z.B. dass der Nickname schon vergeben ist. Wie könnte man da vorgehen?
-
Das Plugin registriert beim Server, auf welche Nachrichten es wartet, zum Beispiel als Nachrichtentyp und Regexp /^nick changed/ und lokaler ID oder so?
-
CodeBlocks, NetBeans, Eclipse, XCode 3 + 4. Möglicherweise hab ich jetzt eine vergessen. Davon ist Eclipse aber immer noch die beste. Gibts sonst noch was erwähnenswertes?
KDevelop!
-
Ich dachte mir, dass ich den Plugins grundsätzlich alle Nachrichten weiterleite und das sortieren dann dort mache. Aber egal, wie das nun aussieht, die Antwort kann ja trotzdem irgendwann kommen...
-
314159265358979 schrieb:
Ich dachte mir, dass ich den Plugins grundsätzlich alle Nachrichten weiterleite und das sortieren dann dort mache. Aber egal, wie das nun aussieht, die Antwort kann ja trotzdem irgendwann kommen...
Und wenn sie kommt, wird sie dem NickchangeJob-Objekt zugeführt. Oder alle laufenden Job-Objekte bekommen alle Zeilen oder alle laufenden Job-Objekte holen sich alle Zeilen. Das hat wohl dann den Nachteil, daß komplexere Handlungen zunächst von der prozedurelen Sicht in endliche Automaten übersetzt werden müssen. Eine Sache, mit der ich nie zufrieden war.
-
Hm, ich habe mir gerade folgendes überlegt: Ich arbeite mit mehreren Threads. 1 Thread fürs lesen und mehrere Threads für die Handler. Wenn dann jemand einen Nickchange ausführen will, ruft er in etwa so eine Funktion auf:
bool change_nick(string newnick) { write_line(nickchange(newnick)); response r = wait_for_response(); return r.success; }Der Handler-Thread wartet also im Hintergrund, während weitere Nachrichten eintreffen und bearbeitet werden können. Dann kann man auch noch timeouts einbauen.
-
314159265358979 schrieb:
Hm, ich habe mir gerade folgendes überlegt: Ich arbeite mit mehreren Threads. 1 Thread fürs lesen und mehrere Threads für die Handler. Wenn dann jemand einen Nickchange ausführen will, ruft er in etwa so eine Funktion auf:
bool change_nick(string newnick) { write_line(nickchange(newnick)); response r = wait_for_response(); return r.success; }Der Handler-Thread wartet also im Hintergrund, während weitere Nachrichten eintreffen und bearbeitet werden können. Dann kann man auch noch timeouts einbauen.
Und jeder dieser Threads lauscht an allen Nachrichten, wozu er sich natürlich beim Server an- und abmelden muß.
Jeder dieser Threads ist also eigentlich das, was bisher ein Plugin war.
-
Nein, die Threads sind nur für die Bearbeitung der Nachrichten zuständig. Gelauscht wird immer nur von einem Thread. Was mir allerdings gerade einfällt: Wenn mehr Nachrichten kommen, als Threads frei sind, gibts ein Problem. Hrmpf.