Home Projects Jobs Clientele Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Log class problems

1. - we agreed I'd change that. It isn't a big deal so no need to argue.
2. - I don't want to derive different buffers. I want to derive different
log classes with one virtual method. This way it's much simplier, doesn't
require to know anything about the implementation of streams, and I don't
see any performance issues.
3. - the alternative is - if the msg is too large we brake it on two parts.

2006/1/31, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
> I took a look at your code. Here are few comments.
> 1. Like I mentioned on IRC, overriding operator<<(ostream&, enum)
>     may not be a good idea due to promotion rules between enums and ints
>     I'd create small wrapper class with const values instead.
> 2. the way you handle actual log output through containing stream seems
>     to go against streams philosophy. Stream does formatting, streambuf
>     does write ops.
>     What I'd do, is define pure virtual saveLog method in CBaseLogBuf,
>     and then override it in derived buffers.
>     Unfortunately C++ does not have a way to prevent derived classes
>     further overriding base class' virtual methods, so you'd have to
> document
>     that overflow() should not be touched.
> 3. Making internal buffer resizable might be an issue - this way attacker
>     could cause logging server to log infinitely large line, which would
>     cause server to run out of memory.
>     Instead just allocate fixed-size buffer.
> Other then that, it looks OK.
> Alexey Parshin wrote:
> >I have finally commited a first draft of very first class - CLogFile, to
> >SPTK, along with the test example. I'd add logger interface in a day or
> two.
> >
> >
> >
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com

Alexey Parshin,

Authoright © Total Knowledge: 2001-2008