On Dec 21, 2006, at 4:21 AM, Tomas Andersen wrote:
Hi!
When using log4cxx I usually do something like this to build the
log string.
std::stringstream oss;
oss << "This is my logging and the result is: ";
int i=getANumber();
if( i == 1 )
{
oss << "1";
}
else
{
oss << "something else";
}
LOG4CXX_DEBUG(logger, oss.str();
nextMethodToCall();
[This works ok.]
One time I added
oss << std::ends;
before the LOG4CXX_DEBUG call.
This log line never appeared in the log and the nextMethodToCall()
method was never called. It seemed like the
thread where this was done hanged in the LOG4CXX_DEBUG call!
Great if you could check that. I'm using the head version of
LOG4CXX downloaded the 19. december this year =)
The behavior sounds consistent with LOGCXX-162 (http://
issues.apache.org/jira/browse/LOGCXX-162?page=all) which was marked
as resolved on 4-Dec-2006. Basically the charset decoder that called
mbstowcs would go into a loop if the string contained a null
character. However, the charset decoder in use depends on the
platform and build settings and it is possible that the same defect
exists in some of the other charset decoders.
Could you let us know what platform and compiler you are using and
any build switches. If you are using the ant build, did the unit
test suite complete successfully. The bug fix for LOGCXX-162 added a
test that should fail if the default character decoder has that type
of flaw. I'm not sure if "make check" works on the autotools build
to do the same thing. There was a recent patch that might have fixed
it.
Another thing while I'm at it:
I have used the LOG4CXX_DEBUG command with concatuating several
std::string(s) as parameters, ie:
LOG4CXX_DEBUG(logger, "This is a string: " + myFirstString + " and
this is another one: " + myOtherString );
It does only work with strings. Do you have any plans of making
this possible for other types aswell (as in log4j)..?
(I know java has the advantage of toString() and that is probably
why this doesn't work right?)
int a = 5;
LOG4CXX_DEBUG(logger, "This is a number test: " + a);
It compiled but resulted in the following logline:
.... - is a number test:
The first word was cut and the integer was never printed.
I believe that "a" was interpreted as being a char or wchar_t value,
basically the same as if you did:
"This is a number test: " + '\u0005';
in Java. If you increase the value of a to 67 or so, you'd should
see an printable character in the log. That is a behavior that is
built into std::basic_string and not much we can do about it.;
log4cxx does contain a logstream class that was intended to make a
std::basic_stream compatible logging interface, however there are
some performance and usability issues around the current
implementation and no obvious way to maintain full compatibility with
std::basic_string and eliminate the performance problem.
You could also create a formatting method that returned a std::string
and use that in place of the message. The macros would short circuit
the evaluation of the formatter if the threshold was not reached.
Something like:
LOG4CXX_DEBUG(logger, cfmt("This is a number test: %d", a));
