On Mar 18, 2008, at 12:01 PM, Jacob L. Anawalt wrote:
Stephen Bartnikowski wrote:
-----Original Message-----
From: Josh Kelley [mailto:[EMAIL PROTECTED]
LOG4CXX_DEBUG(logger, "Read " << path << " and got " << out);
Nice. I hadn't tried that since 'message' was documented to expect a
string and I didn't know if it would break in future versions, so I
had written out the long form of what the macro wrapped. I will be
correcting that shortly.
this:
#define LOGGING_DEBUG(message) { \
if ((*pLogger)->isDebugEnabled()) {\
log4cxx::logstream oss(*pLogger, log4cxx::Level::getDebug());\
oss.setLocation(LOG4CXX_LOCATION);\
oss << message;\
oss.end_message();}}
This assumes you have the following declared and initialized:
log4cxx::LoggerPtr* pLogger;
I see that the current online API documentation doesn't use the
logstream, and have read Curt's response saying it is supported once
again. If it hadn't been, I was thinking that the current online API
docs looked a little more efficient for simple strings (which is
where I currently use the logging macros), and that I would re-
implement the older style macros as LS_LOG4CXX_*(logger,streamInput).
I don't follow the last sentence. The current macro definitions (and
the implementation of the supporting classes) attempts to avoid the
use of an actual std::basic_ostream if possible, so it should be more
efficient for logging simple strings than the 0.9.7 implementation or
an alternative using logstream.
I hope the auto-detecting methods work well. If they didn't or again
if the "stream in the macro" version hadn't returned and I needed
wchar_t support I probably would have taken the "add a W to the
macro name" easy way out (LSW_LOG4CXX_*(logger,wideStreamInput)).
Adding W would not transparently support logging TCHAR* (programming
model used on Windows where TCHAR either char or wchar_t depending on
preprocessor macros). The LOG4CXX_ macros needed to effectively
perform parameter matching (which compiler does, but not the
preprocessor) to determine the matching stream type.
