Re: Log class problems

[Alexey Parshin <alexeyp@gmail.com>]

2. Nope. I don't like it. You lose :P
3. Ok. I don't think it will happen too often, anyway.

2006/1/31, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
>
> 2. With my propositions one need not know anything about iostreams
>     Instead one will need to override single method - saveMessage,
>     but in LogStreamBuf, not in LogStream. This is not performance issue
>     (performance will be the same), but instead it's philosophy issue.
>
>     As for simplicity - my way there is only one-way tie between stream
> and streambuf,
>     and you have two-way tie. I win.
>
> 3. We'll break it in my case as well. Just in my scenario you don't need
> to
>     even think about memory allocation/deallocation. Everything will be
>     taken care of automatically.
>
> Alexey Parshin wrote:
>
> >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,
> >http://www.sptk.net
> >
> >
> >
>
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
>
>


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