C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  [CK] Logger          C++Talk.NET Forum Index -> C++ (German) View previous topic :: View next topic   Author Message Markus Brueckner Guest Posted: Wed May 31, 2006 1:52 am    Post subject: [CK] Logger Moin, in de.rec.fotografie gibt es ja immer die BK==Bildkritik, daher stelle ich hier mal eine CK==Codekritik. Als Fingerübung um ein wenig mit Templates warm zu werden habe ich mir schon vor längerer Zeit eine Logging-Klasse geschrieben, die wie ein std::ostream benutzt werden soll und dabei noch so nette Features wie das Ein-/Ausschalten von Trace-Nachrichten bietet. Irgendwann ist das ganze etwas außer Kontrolle geraten und es kam noch der Wunsch (bei meinem Arbeitgeber) nach Thread-Sicherheit auf (nicht hauen, ich weiß, daß das hier OT ist.) Jedenfalls wollte ich, nachdem ich soweit mit dem Teil zufrieden bin, euch mal um Kritik bitten. Was findet ihr gelungen? Was verbesserungswürdig? Was würdet ihr ganz verwerfen? Was zusätzlich reinbringen? Das ganze ist ein einzelnes Headerfile und ist daher (hoffentlich) recht einfach zu benutzen. Den Code gibt es auf https://vcs.slash-me.net/snippets/logging/ , die bereits generierte Doxygen Doku mit ein paar einleitenden Zeilen auf http://www.slash-me.net/dev/snippets/logging/ Danke schonmal für eure Kommentare. Bis dann Markus -- "Ach nee, Katastrophentourismus..." - higgins zu einer Fotografin während einer Stoiber-Rede - http://www.das-motto-des-tages.de -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Andreas Huennebeck Guest Posted: Wed May 31, 2006 1:02 pm    Post subject: Re: [CK] Logger Markus Brueckner wrote: Quote: in de.rec.fotografie gibt es ja immer die BK==Bildkritik, daher stelle ich hier mal eine CK==Codekritik. Klar, warum nicht. Quote: Als Fingerübung um ein wenig mit Templates warm zu werden habe ich mir schon vor längerer Zeit eine Logging-Klasse geschrieben, die wie ein std::ostream benutzt werden soll und dabei noch so nette Features wie das Ein-/Ausschalten von Trace-Nachrichten bietet. Irgendwann ist das ganze etwas außer Kontrolle geraten und es kam noch der Wunsch (bei meinem Arbeitgeber) nach Thread-Sicherheit auf (nicht hauen, ich weiß, daß das hier OT ist.) Threadsicherheit ist hier IMHP nicht OT, Höchstens deren systemabhängige Implementierung. Quote: Jedenfalls wollte ich, nachdem ich soweit mit dem Teil zufrieden bin, euch mal um Kritik bitten. Was findet ihr gelungen? Ich finde, Du hast Deinen Alexandrescu (Modern C++ Design) ganz gut studiert. Quote: Was verbesserungswürdig? - Die Preprozessor-Makros sollten einen eindeutigen Prefix (z.B. "LOG_") haben, sonst kommst Du schnell in Namenskonflikte. - Der Name "Logging" als Namespace ist IMHO nicht gut gewählt; sollte eher ein Firmenname oder Libraryname sein. Das ist aber nun wirklich kein Punkt der Kritik. - Wenn man template <bool, class TMutex> class TTraceStream nicht direkt verwenden darf, sollte man das mit Compilermitteln verhindern (z.B. den Konstruktor protected machen). Quote: Was würdet ihr ganz verwerfen? Was zusätzlich reinbringen? Ich habe nicht genug Zeit, um mich damit richtig auseinanderzusetzen. Auf den ersten Blick erscheint mir das ganze etwas kompliziert (ist halt nicht selbst geschrieben , und es kommen mir zuviele friend-Deklarationen darin vor. Ich würde versuchen, möglichst viele Implementierungsdetails mit Policyklassen zu erschlagen (also so, wie Du es mit dem Mutex gemacht hast), und die Hauptklasse dadurch klein und übersichtlich zu halten. Tschau Andreas -- Andreas Hünnebeck | email: acmh (AT) gmx (DOT) de ----- privat ---- | www : http://www.huennebeck-online.de Fax/Anrufbeantworter: 0721/151-284301 GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc PGP-Key: http://www.huennebeck-online.de/public_keys/pgp_andreas.asc -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Robert W. Kuhn Guest Posted: Wed May 31, 2006 2:06 pm    Post subject: Re: [CK] Logger Andreas Huennebeck schrieb: Quote: Ich würde versuchen, möglichst viele Implementierungsdetails mit Policyklassen zu erschlagen -v bitte. Wenn ich google danach befrage, schlägt es mir vor, lieber nach Poloklasse zu suchen... Tschau - Robert -- vertrau voraus voraus -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Jens Müller Guest Posted: Wed May 31, 2006 2:16 pm    Post subject: Re: [CK] Logger Robert W. Kuhn wrote: Quote: Andreas Huennebeck schrieb: Ich würde versuchen, möglichst viele Implementierungsdetails mit Policyklassen zu erschlagen -v bitte. Wenn ich google danach befrage, schlägt es mir vor, lieber nach Poloklasse zu suchen... Siehe Gang of Four (Gamma et al., Design Patterns): Da gibt es ein Policy-Muster. Da geht es dann noch um Objekte, die das Verhalten eines Objektes steuern. Mit der Kompilierzeitparametrisierbarkeit durch Templates in C++ kann man dann das Verhalten einer Klasse steuern, indem man Policy-Klassen, die jeweils ein genau abgegrenztes Verhaltensmerkmal kapseln, als Template-Parameter übergibt. Das ist dann auch schön effizient, weil es zur Kompilierzeit in den Code "eingewoben" werden kann. Siehe auch Alexandrescu, Modern C++ Design. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Daniel Albuschat Guest Posted: Wed May 31, 2006 3:22 pm    Post subject: Re: [CK] Logger Robert W. Kuhn wrote: Quote: Andreas Huennebeck schrieb: Ich würde versuchen, möglichst viele Implementierungsdetails mit Policyklassen zu erschlagen -v bitte. Wenn ich google danach befrage, schlägt es mir vor, lieber nach Poloklasse zu suchen... Ueber Policies lagerst du Implementierungsdetails (z.B. wie ob ein shared_ptr threadsafe ist oder nicht) in Klassen aus. Hier ein Pseudo-Beispiel: struct shared_ptr_policy_default { static void mache_etwas() { /* ... */ } }; // Policy-Klasse nicht thread-safe struct shared_ptr_policy_threadsafe { static void mache_etwas() { CreateMutex(); shared_ptr_policy_default::mache_etwas(); ReleaseMutex(); } }; // Policy-Klasse thread-safe template<typename ThreadPolicy> struct shared_ptr { void mache_etwas() { ThreadPolicy::mache_etwas(); // Je nach Policy thread-safe oder nicht } }; Das war jetzt "In-A-Nutshell". Im Alexandrescu, den Andreas auch bereits erwaehnt hat, findest du viel mehr dazu. Und noch weitere tolle Programmiertricks. MfG, Daniel -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Torsten Robitzki Guest Posted: Wed May 31, 2006 3:22 pm    Post subject: Re: [CK] Logger Markus Brueckner wrote: Quote: Moin, Moin Moin, Quote: Danke schonmal für eure Kommentare. Gibt es einen Grund, warum Du nicht das "übliche" Vorgehen gewählt hast und einen entsprechenden stream buffer implementiert hast? Das hätte den Vorteil das code, der mit einem ostream arbeitet auch mit Deinem Logger arbeiten könnte. Im ersten Beispiel wird der Logger ohne Not dynamisch angelegt. Es gibt Menschen, die lesen _nur_ die Beispiele und verwenden sie so (oder was glaubst Du ist der Grund, warum Menschen ihr Variablen mySonstwas nennen ;-) Die Makros würden mich stören. Für ENTER könnte man einfach: inline Logging::Logger& enter(Logging::Logger& l) { return l << Logging::LEVEL_TRACE << "Entering "; } schreiben und eine entsprechende Funktion im Stream implementieren, die einen Manipulator nimmt, so wie Du es ja für die std::ios_base gemacht hast. Im Gegensatz zu Robert finde ich den namespace Namen treffend (ich würde ihn allerdings komplett klein schreiben). An Traceleveln würde ich evtl. noch mehr Details vor INFO (z.B. LEVEL_DETAIL, LEVEL_ALL) einfügen, für den Fall, das man auch sehr viele Details zur Laufzeit in einem release build auswerten wollte. mfg Torsten -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Markus Brueckner Guest Posted: Wed May 31, 2006 4:20 pm    Post subject: Re: [CK] Logger Andreas Huennebeck <acmh (AT) gmx (DOT) de> writes: Quote: Markus Brueckner wrote: [...] Threadsicherheit ist hier IMHP nicht OT, Höchstens deren systemabhängige Implementierung. Naja, da C++ keine Threads kennt... Aber ok, prinzipiell stimme ich dir zu. Quote: Jedenfalls wollte ich, nachdem ich soweit mit dem Teil zufrieden bin, euch mal um Kritik bitten. Was findet ihr gelungen? Ich finde, Du hast Deinen Alexandrescu (Modern C++ Design) ganz gut studiert. *g* Danke. Wenn ich das nur hätte. Aber ich hab ihn erst vorige Woche bestellt und ware noch ganz sehnsüchtig drauf. Ich bin gespannt, was der so bietet. Quote: Was verbesserungswürdig? - Die Preprozessor-Makros sollten einen eindeutigen Prefix (z.B. "LOG_") haben, sonst kommst Du schnell in Namenskonflikte. Nicht nur das. Während der Entwicklung (Leute mit einem Subversion-Client können sich von der genannten URL ja alle Versionen ziehen und das nachvollziehen) hießen die Log-Level ursprünglich ohne den Präfix LEVEL_. Nun, der Level mit dem Namen DEBUG sorgt im Debug-Modus unter Visual C++ für interessante Effekte. Keine Ahnung, wozu der durch ein Makro ersetzt wird, aber der Compiler mag es gar nicht. Soviel zum Thema: Wir packen es in einen Namespace um Konflikte zu vermeiden. Quote: - Der Name "Logging" als Namespace ist IMHO nicht gut gewählt; sollte eher ein Firmenname oder Libraryname sein. Das ist aber nun wirklich kein Punkt der Kritik. Ich fand ihn hier naheliegend und unproblematisch. Es wird schließlich hoffentlich kaum jemand zwei Logging-Frameworks gleichzeitig in einer Software einsetzen wollen. Quote: - Wenn man template <bool, class TMutex> class TTraceStream nicht direkt verwenden darf, sollte man das mit Compilermitteln verhindern (z.B. den Konstruktor protected machen). Danke, auf die Idee bin ich noch gar nicht gekommen. Quote: Was würdet ihr ganz verwerfen? Was zusätzlich reinbringen? Ich habe nicht genug Zeit, um mich damit richtig auseinanderzusetzen. Auf den ersten Blick erscheint mir das ganze etwas kompliziert (ist halt nicht selbst geschrieben , und es kommen mir zuviele friend-Deklarationen darin vor. Ja, die Komplexität geht mir manchmal auch ein wenig auf die Nerven. Wenn ich mal viel Zeit habe... Allerdings will ich das Interface gern beibehalten. Quote: Ich würde versuchen, möglichst viele Implementierungsdetails mit Policyklassen zu erschlagen (also so, wie Du es mit dem Mutex gemacht hast), und die Hauptklasse dadurch klein und übersichtlich zu halten. In das Thema muss ich mich dann erst noch einlesen. Der Mutex war für mich die naheliegendste Lösung als Template-Parameter. Wie und wo ich da noch weitere Sachen ersetzen könnte, muss ich noch schauen. Bis dann Markus P.S: Evtl. könnte das ja mal jemand noch weiteren Compilern vorwerfen? Ich hab bisher GCC 2.95, 3.3 und 4.0 und VC++ .NET getestet. Weitere Ergebnisse würde mich interessieren. -- "Windows" is not the answer. "Windows" is the question and the answer is "no". - StickyBit auf heise.de - http://www.das-motto-des-tages.de -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Markus Brueckner Guest Posted: Wed May 31, 2006 5:20 pm    Post subject: Re: [CK] Logger Torsten Robitzki <MyFirstname (AT) Robitzki (DOT) de> writes: Quote: Gibt es einen Grund, warum Du nicht das "übliche" Vorgehen gewählt hast und einen entsprechenden stream buffer implementiert hast? Ja. Der Trick mit dem Rausoptimieren im Releasecode hätte meiner Meinung nach nicht mehr funktioniert. Soweit bin ich allerdings mit den streambufs nicht vertraut, daß ich das 100% sicher sagen kann. Quote: Das hätte den Vorteil das code, der mit einem ostream arbeitet auch mit Deinem Logger arbeiten könnte. Der Logger ist mehr ein Frontent für einen std::ostream. Sprich: du kannst alle std::ostream-kompatiblen Dinge als Backend verwenden. Deine Ausgabeoperatoren musst du auch nur normal für std::ostream definieren. Quote: Im ersten Beispiel wird der Logger ohne Not dynamisch angelegt. Es gibt Menschen, die lesen _nur_ die Beispiele und verwenden sie so (oder was glaubst Du ist der Grund, warum Menschen ihr Variablen mySonstwas nennen *g* Jaha. Das Beispiel soll halt verdeutlichen, wie der Logger wohl häufig verwendet werden wird. So kann man nämlich dynamisch bestimmen, wo die Ausgabe hingeht. Quote: Die Makros würden mich stören. Für ENTER könnte man einfach: inline Logging::Logger& enter(Logging::Logger& l) { return l << Logging::LEVEL_TRACE << "Entering "; } schreiben und eine entsprechende Funktion im Stream implementieren, die einen Manipulator nimmt, so wie Du es ja für die std::ios_base gemacht hast. Hm, das muss ich mir mal vormerken. Das spart wieder ein wenig Präprozessor. Quote: Im Gegensatz zu Robert finde ich den namespace Namen treffend (ich würde ihn allerdings komplett klein schreiben). An Traceleveln würde ich evtl. noch mehr Details vor INFO (z.B. LEVEL_DETAIL, LEVEL_ALL) einfügen, für den Fall, das man auch sehr viele Details zur Laufzeit in einem release build auswerten wollte. Mir fällt keine wirklich passende Semantik für die von dir genannten Level ein. Deswegen sind's ja so wenige. Nicht daß die Erweiterung wirklich kompliziert wäre. Bis dann Markus -- "Windows" is not the answer. "Windows" is the question and the answer is "no". - StickyBit auf heise.de - http://www.das-motto-des-tages.de -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (German) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.