Re: Log class problems

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

Eeee.. It makes no sense. Why have
Common log interface if you still
need to know which specific kind of
Logger you are working with?

Btw - all those things do make sense
For all mentioned kinds of logs.

Think about marking records accordingly and filtering them later on.

-----Original Message-----
From: Alexey Parshin <alexeyp@gmail.com>
Date: Tue, 31 Jan 2006 13:07:40
To:C++ Servlet Engine Discussion <cppserv@total-knowledge.com>
Subject: Re: Log class problems

I don't want single CLogStream! I want to have several classes that are
really easy to customise.
Some elements of CSysLog class, like facilities, have absolutely no use for
CLogFile.. And the file name in CLogFile means nothing for CSysLog.. And
both, facilities and filename, mean nothing for CMemoryLog.

I want only one change for now. I want to rename CLogFile to CFileLog, and
separate it from CBaseLog - to different file. File names should change
accordingly.

2006/1/31, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
>
> In my method, one would need to override single function just as well.
> Most of your current overflow() code would stay the same - just the
> virtual saveLog() function would need to be overwritten. This isn't
> any more complex then what you propose.
>
> There are reasons, why C++ iostreams are designed the way they are.
> In the design I'm proposing one wouldn't need to derive from CLogStream
>_at all_. There would be singel CLogStream class, that provides intrfaces
> for setting log priorities and stuff like that, that are common to all log
> classes, and then it would be used with different buffers for different
> destinations.
>
> (This is slight deviation from my original thinking, where I didn't
> realize
> there is no need to further derive CLogStream)
>
>
> Alexey Parshin wrote:
>
> >2. I gave you my arguments. Writing a new log class is much simplier in
> the
> >current implementation. Considering that I'm not trading off anything -
> >that's enough. To add even more - I don't want to explain in
> documentation -
> >"don't you dare to overwrite overflow(), or it would stop working!".
> Current
> >implementation requires to ovewrite a single method with a parameters
> >providing full info about what should be done. That's an idiot-proof
> method.
> >
> >
> >
>
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
>
>


--
Alexey Parshin,
http://www.sptk.net