On Dec 22, 2004, at 4:33 PM, Christopher Sm ith wrote:
With the normal idiom for logstreams you would want different streams for each log level which would avoid this issue entirely.
What "normal" idiom? I'm not aware of any established patterns for using a STL stream-like interface for logging. If there are, references would be nice and we can add their ideas in the mix in addition to yours and mine.
I referenced log4cpp's streams. I've used others, although normally they were internal tools and as such not available. As I recall, in the log4cpp model a logstream is used only for a single logging event.
What I was anticipating is that you would construct the logstream on entry to a method (or have it passed in as a reference) and use it for all log requests within the message body.
Okay, this was the original model I had envisioned when I suggested logstreams in the first place, which was why I made the effort to avoid constructing a stream unless one was actually needed (hence the use of delegation instead of inheritence). I thought your feedback about having to construct a new logstream being atypical suggested a model where logstreams would be far more durable than just a single method call. If were going with creating them once per method, I should think we'd want the overhead of logging when disabled to be in the 40-50ns range rather than the 1000ns+ range that I get when I construct an iostream.
If I was doing:
filestream << "We have: " << std::scientific << 3.1415926 << std::endl;
At the end of the statement, I would expect that either an exception had been thrown (disk full, etc) or the filestream would have be left with the file stream using scientific notation.
You would also expect that either an exception had been thrown or the filestream had written out "We have: " and written and end of line and done a flush. Now, which is more surprising: that the logstream might not have done all of that if the log level wasn't enabled, or that it did none of what I said, but all of what you said? It is probably one of those matter of perspective things, but to me it seems far more logical that all operator<< stuff either be a nop or not, rather than just some of it.
--Chris
