Re: [boost] Review of Logging library begins today February 4th

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-02-05 18:06:50

AMDG

John Torjo wrote:
> I wanted a standard way of implementing a manipulator that holds non 
> constant data.
>
> Users will usually look at existing code and then develop their-own. 
> Using shared_ptr<> could easily be overlooked, and people could would 
> end up with a badly implemented manipulator.
> Also, non_const_context makes sure the shared_ptr doesn't point to 
> null - syntactic sugar.
>
> To answer your question : you can use shared_ptr, but the recommended 
> way is to use non_const_context.

And in addition, non_const_context is a slightly higher level of 
abstraction.
The disadvantage I see is that copying such a manipulator may cause 
surprises
and using shared_ptr directly makes it more obvious that copying doesn't 
quite
have normal semantics.
 
> Depends on what you want - the library is very flexible when it comes 
> to filters. The simplest level holders looks like this:
>
> // the higher the level, the more critical the message
> struct level_filter {
>    level_filter(int default_level = 0) : m_level(default_level) {}
>    bool is_enabled(int level) const { return level >= m_level; }
>    void set_enabled(int level) {
>        m_level = level;
>    }
> private:
>    int m_level;
> };

So the minimum needed to interoperate with LOG_IF_LEVEL is
bool is_enabled(int level)?

>>
>>   If manipulators are effectively function objects, I would like to 
>> be able
>> to just plug in existing function objects like those created by 
>> bind.  If there
>> isn't anything more to specialize then you should re-use existing 
>> concepts.
>>
>>   
> There's more to manipulators than just being a functor:
> - they need to have some inner typedefs, and they provide the 
> possibility to be configured.

As far as the logging framework is concerned, is there any particular reason
that you need to support configuration directly?  Why can't there just be an
interface for accessing manipulators.  Oh.  I get it.  You've lost the 
static
type information.  I'll shut up now until I have time to look at the 
implementation.
  
>>> "for formatters the result should be the same as the argument type"  
>>> - why?
>>>       
>>
>> Because the result may have to be passed on to other formatters, of 
>> the same
>> static type right?  Or am I completely misunderstanding how 
>> formatters work?
>>
>>   
> They don't work like that. A formatter gets a string as argument to 
> its operator(), and it manipulates that string.
> So each manipulator works isolated from the other formatters.

In place manipulation.  Doh.  (Sounds like I've been doing too much 
functional programming recently)

In Christ,
Steven Watanabe