Re: [boost] [logging] Interest check on logging library.

Subject: Re: [boost] [logging] Interest check on logging library.
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-01-01 19:22:42

Gordon Woodhull wrote:
> 
> On Jan 1, 2009, at 5:11 PM, Andrey Semashev wrote:
>> That is your choice, indeed. However, in general, this will not allow 
>> you to immediately see if the record will be processed or not. This is 
>> because filters are usually set up in some initialization code, which 
>> is rather remote from places where you actually write logs.
> 
> I believe what Jason is talking about is compile-time filtering where 
> the compiler actually does know the answer and is able to eliminate 
> code.  The "trivial 'if'" is gone after optimization.  This seems like a 
> very nice feature to me.

I agree that this is a very useful feature. One of my points in the 
reply to Jason was that there are simpler and more efficient ways to do 
it than employing metaprogramming and hoping that the optimizer does the 
rest. The other point was that, the way it is presented now, the 
proposal does not combine well with run time filtering, which, I think, 
is no less useful.

> (earlier post:)
>> writing the result of a function call, like dump_hex in your example. 
>> I didn't investigate this, but I suspect the call will still be 
>> present in the compiled code, which, AFAICT, is not what you intended.
> 
> These is what the lazy function evaluation is for.  It seems to me that 
> lazy functions are going to be necessary for any non-macro solution that 
> doesn't require ifs in user code, but they might also be helpful with 
> the runtime filtering you are talking about?

Although lazy functions solve the problem, they complicate logging a 
lot. If you just want to put to log the result of a function call, you 
have to create a lambda expression or some functional wrapper for that 
call. I know, this is quite simple with Phoenix or Lambda, but this is 
still quite an amount of scaffolding for such a trivial task.