Re: The usefulness of application logging
Hendrik Schober wrote:
[...]
Also, I frequently log
to Windows' 'OutputDebugStr()' API function that takes
an 'const char*' (and lets me see this in the debugger,
where clicking that log message takes me to the line
that produced it). I don't see a reason to spend time
building a stream buffer that writes into this.
A strstreambuf will handle dynamic expansion of the buffer
automatically:-).
I never said I won't /use/ a stringstream for that. ;^)
But if you log into a stream, you need a stream buffer
to write to wherever log messages are suppsoed to be
written to. In the std lib there's only those which
write to files. (That's seeing stdout et.al. as files.
Also, a string in memory that's owned by the stream
buffer isn't very helpful, so I disregarded string
streams here.) For everything else you will thus have
to write your own stream buffer. And I believe that
rather few people would (want to) do that.
It's really not difficult. I don't use stringstream here
either. Depending on the case strstreambuf could be useful, but
I generally prefer full control over the buffer myself. I don't
want it to be freed when I clear it after a flush, for example.
There is some justification for not using streambuf's for the
final destination. You don't need most of what streambuf
offers, and you often do need to control very precisely when the
"flush" (the physical write) occurs. For a filebuf, an extra
write in the middle of a trace (a trace with a very long
message) isn't really a killer, but the streambuf's you write
for syslog and emails definitly should only synchronize (send
the message) when explicitly told to do so.
If I were doing this today, I think I'd buffer in an
std::vector<char> in the top level streambuf, and use a custom
abstract class, with a single pure virtual function write, for
the individual destination handlers. My previous
implementations (all actually written before I had access to the
STL) forwarded each character to all of the destination
streambuf's, and called sych (today pubsync) at the end of each
message; each destination streambuf handled buffering as best it
saw fit. But thinking it over, I don't think it's the best
solution: there's no need for n separate buffers for n different
sinks.
I would definitly use ostream for formatting, however (unless
internationalization became an issue). Which means that the top
level router is a streambuf.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]