On Nov 5, 2007, at 8:55 AM, Steck, David wrote:
I used the logstream class throughout my code, liking that I could use
it like cout.
My preference is to see one of the following:
1) If the implementation of logstream were changed from
basic_ostringstream to a MessageBuffer, would that make logstream work
more satisfactorily? (I don't remember at the moment what the issues
were.)
2) Perhaps the new logging macros, or something similar, could be
wrapped in a class that works like the logstream class.
3) Leaving logstream deprecated would certainly help me, since I won't
have time to re-work any of the logging framework for a while, but I'd
like to use the newly released version when I do.
4) If not 1) or 2) above, then I'd appreciate advice on how I could
wrap
the internals of the new logging macros in my own logstream-like
class.
Thank you,
-David
I'm re-reworking MessageBuffer at the moment since VC6 apparently
doesn't support different return values for different operator<<
functions on the same class which was a key part of the previous
message buffer rework.
1) The issue with logstream is that its construction was relatively
expensive on some platforms (due to the surprisingly expensive
std::ostring constructor) and would occur regardless of whether any
configuration setting. Would not be a problem if created a logstream
at the head of a long-running function, but would be a problem if
placed at the head of a frequently called, short-running function.
It could be potentially be rewritten to encapsulate a std::ostream
which could defer (or potentially eliminate) the bulk of the
construction expense, but then you could not pass it to any function
that took a std::ostream&. The problem was trying to write something
that was both a true std::ostream and was nearly invisible when
logging was disabled.
2) The new macros should now work similar to the logstream class in
that insertion operators can be used in the message parameter.
However, it is not possible (or desirable) to maintain state between
successive macro expansions. For example:
ls << Level::getInfo() << std::scientific;
ls << "e^20=" << exp(20.0) << LOG4CXX_ENDMSG;
ls << "log(10)=" << log(10.0) << LOG4CXX_ENDMSG;
and
LOG4CXX_INFO(std:: scientific);
LOG4CXX_INFO("e^20=" << exp(20.0));
LOG4CXX_INFO("log(10)=" << log(10.0));
Do not do the same thing since there is nothing that preserves state
between the macro expansions. However, you could do:
LOG4CXX_INFO(std::scientific << "e^20=" << exp(20.0));
LOG4CXX_INFO(std::scientific << "log(10)=" << log(10.0));
3 or 4) It should be one of these two. Will likely do some kind of
vote around the first release candidate. If it doesn't remain in the
release, then you could still continue to use it by just keeping the
logstream.h file in your include path.
