Curt Arnold wrote:
On Mar 18, 2008, at 12:01 PM, Jacob L. Anawalt wrote:
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 hadn't looked at how the latest (svn HEAD) auto-detecting method worked, so I
was going off of your statement that "...experimentation hopefully results...",
and stating that in case it didn't, I could simply fall back to writing my own
macros like the 0.9.7 ones.
Since 'current' seemed to get a little blurred, this is what I was referring to:
1) 0.9.7 version:
#define LOG4CXX_DEBUG ( logger, message ) { \
if (logger->isDebugEnabled()) {\
::log4cxx::StringBuffer oss; \
oss << message; \
logger->forcedLog(::log4cxx::Level::DEBUG, oss.str(), __FILE__,
__LINE__); }}
2) current online API docs:
#define LOG4CXX_DEBUG (logger,message) { \
if (LOG4CXX_UNLIKELY(logger->isDebugEnabled())) {\
logger->forcedLog(::log4cxx::Level::getDebug(), message,
LOG4CXX_LOCATION); }}
It seemed to me that 2 is more efficient than 1 when the argument to the macro
is either a static string, eg "Hello World", or a std::string containing some
string my program needed to generate anyway because 2 does not create a
temporary StringBuffer and avoids the << and str() function calls.
3) this morning's svn HEAD (which I wasn't referring to before):
#define LOG4CXX_DEBUG ( logger, message ) { \
if (LOG4CXX_UNLIKELY(logger->isDebugEnabled())) {\
::log4cxx::helpers::MessageBuffer oss_; \
logger->forcedLog(::log4cxx::Level::getDebug(), oss_.str(oss_ <<
message), LOG4CXX_LOCATION); }}
Taking an initial look at 3 this morning, it appears to create a temporary
object, and call << and str() as well. Based on what you have said about 3
avoiding creating an ostream, it must be more efficient than 1 and possibly only
slightly less efficient than 2. Someone needing that extra boost and only using
strings may prefer to duplicate 2 with their own localized name.
Adding W would not transparently support logging TCHAR*
True, and MessageBuffer appears to be a clever solution to this.
I haven't had luck with everything 'just working' when defining UNICODE or not
so instead I specify what my stream and character types are and define
conversion boundaries within the software. The days are fading away where I even
care to write something new for MS Windows desktops that isn't UNICODE inside. I
am glad you have a solution that works for all of us.
Thank you,
--
Jacob Anawalt
Gecko Software, Inc.
[EMAIL PROTECTED]
435-752-8026
