Codedesign: Logging Class

Chris++ 0

viande schrieb:

Außerdem sieht man nicht sofort, was da passiert und der Anwender der Loggingklasse muss sich darüber Gedanken machen, dass die Klasse als Singleton implementiert ist.

Andererseits sieht der Anwender sofort das es sich um ein Singleton handelt.

Maddes schrieb:

trotzdem geht an makros kein weg vorbei

hmmf, ja, das durft ich grad selbst herausfinden
wenn ich zum Beispiel
log(1) << "foo " << "bar";
habe, schreibt er:

DEBUG: hallo DEBUG: bar

das ist natürlich auch Quatsch. Dort müsste man wahrscheinlich eine Flag setzten, wenn DEBUG (oder was auch immer) ausgegeben wurde, und bei einem Newline diese wieder löschen. Oder so in der Art

nein, da müßtest du zu tief in die stream-klassen einsteigen. eher gar nicht auf ein Newline achten, sondern ein

struct EndLogLine{
};
const EndLogLine endLogLine;

und
log(1) << "foo " << "bar" << endLogLine;

besser fühlt sich für mich an

//ungetestet
char *loglevelNames[]={"DEBUG",...};
enum Loglevel{DEBUG,...};
class LogProxy{
   ofstream file;
public:
   LogProxy(Loglevel loglevel)
   :file("log.txt"){
      file<<getTimeString()<<' '<<loglevelNames[loglevel]<<": ";
   }
   ~LogProxy(){
      file<<'\n';
   }
   friend template<typename T>
   LogProxy operator<<(T& t){
      file<<t;
      return *this;
   }
};
#define LOG(level,tolog) \
#if (level)>=(LOGLEVEL) \
  LogProxy(level)<<tolog
#endif

...

LOG(DEBUG,("user "<<getUserName()<<" hat sich eingeloggt."));
...
LOG(DEBUG,("foo("<<x<<','<<y<<")="<<foo(x,y));

Maddes schrieb:

// am Anfang
int main() {
  Log::open( "name.log" );
  ...
}
// in einer x-beliebigen Funktion
Log::write( "dies wird geloggt" );

nö, eher nicht. es mag zwar ein wenig performance bvringen, das file nicht für jede zeile (bei mir sinds ja zeilen und nicht <<-aufrufe) zu öffnen und zu schließen, aber gemeinerweise sind die fehler, die das prog hart terminieren und dabei dann lustigerweise eine halbgeschriebene logdatei zurücklassen die gemeinsten. logs zu debuggingzwecken sollten dafür sorgen, daß wenn man vor einen kritischen aufruf eine logzeile sendet, die auch echt gespeichert ist, bevor der kritische aufruf ausgeführt wird.
das dauernde öffnen und schließen mag performance kosten. vielleicht reicht auch offenhalten und nach jeder zeile flushen. vielleicht auch nur fluschen in einem bestimmten loglevelbereich.
sollte trotzdem das logging wegen des flushens zu lahm sein, ist es natürlich angebracht, das flushen doch wegzumachen. oder, wenn man ein wenig zeit hat, loggt man einfach nicht in eine datei, sondern in eine pipe eines parallel gestarteten programms. das andere programm kann nicht vom sterbenden prog runtergezogen werden, weshalb es nie flushen muss. vielleicht startet der loggende prozess den pipe-to-file-prozess beim start und zwar so, daß der pipe-to-file-prozess nicht child ist, sondern am leben bleibt, wenn der loggende prozess stirbt. und der pipe-to-file-prozess überwacht den loggenden prozess und wenn der stirbt, flusht er und begeht selbstmord. überwachen? er begeht einfach selbstmord, wenn die pipe zusammenbricht. fühlt sich schon nach füchterlich guter performance an (aber meistens den aufwand nicht wert). andererseits, sowas muss kann man ja immer wieder benutzen.