logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: Status of stream.h?
Date Tue, 07 Jun 2005 00:40:26 GMT

On Jun 6, 2005, at 4:00 PM, Paul Butcher wrote:



> Thanks for the various responses on this topic.
>
> On Monday 06 June 2005 19:57, Curt Arnold wrote:
>
>
>
>> It has been stalled for quite some time, however Christopher Smith
>> has expressed interest in restarting it.  The semantics shouldn't
>> change much but ...
>>
>>
>>
>
> I haven't looked into it in great detail, so can't suggest a  
> solution, but I
> suspect that it will need a change to the semantics to be useful.  
> At the
> moment, very simple constructs like:
>
>   log4cxx::logstream ls(logger, Level::DEBUG);
>   std::string s = "Test";
>   ls << s;
>
> fail (with a very long template-related error message which I won't  
> reproduce
> here).
>
>
>

Hard to troubleshoot without that error message.  Could you at least  
tell me what compiler and platform that you are encountering the  
problem on?





> It seems to work with simple types (char*, int, etc) but not with  
> anything
> more complex :-(
>
>



>
>
>




> Thanks - but am I right in thinking that this isn't available in  
> log4cxx just
> yet?
>
>
>


It is there for feedback and development.  If you can give a little  
more details maybe we can get it working for you in very short order.




> What I've been doing for the time being is this kind of thing:
>
>   std::ostringstream message;
>   message << ... ;
>   LOG4CXX_DEBUG(logger, message.str());
>
>

The std::ostringstream constructor is extremely expensive on some STL  
implementations.  The current logstream implementation is better than  
that, but doesn't approach a NOP when logging is disabled..




>
> or, if efficiency matters:
>
>   if(logger->isDebugEnabled())
>   {
>     std::ostringstream message;
>     message << ... ;
>     LOG4CXX_DEBUG(logger, message.str());
>   }
>
> Is this the best option with the package as it currently stands? Or  
> is there a
> better alternative?
>
>

Fixing the logstream at least enough for your immediate needs would  
be a better alternative, getting it performant would be even better.   
If those aren't achievable in your timeframe, then it would be better  
for you to define a few macros or functions than to reproduce that  
boilerplate code.



Mime
View raw message