Re: Possible error with logging a stringstream

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));