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

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-02-05 15:25:51

AMDG

John Torjo wrote:
> See http://torjo.com/log2/doc/html/caching.html for the rationale.
> However, for a named_logger, we might be able to avoid caching - that 
> is, initialize it in one step.
>   

I see.

> Note that in the future I want to make caching a policy - I just didn't 
> have time to do it before the review.
>   

Ok.

>> Concepts as Namespaces:
>> I strongly dislike this way of expressing it.  What you mean is
>> that you put implementations of that concept in a specific
>> namespace.  The concept, per se, has no relation to the namespace.
>> This description is very misleading, IMO.
>>
>>   
>>     
> Actually I think this is way too cool. First of all, it's very easy to 
> find everything that is related to a concept:
> - in the documentation - just click on that namespace
> - when using code completion
>
> In fact once you get used to the library, you'll see that gets easier 
> and easier to read the code/docs.
> I don't know if any other lib has done this before - but please give it 
> a shot first ;)
>   

That's fine, but a concept is not a namespace.  A concept is a set of 
requirements.
I have no problem with putting everything associated with a particular 
concept
in a single namespace.  What I object to is your terminology.

>>
>> Is there a way to have destination specific formatters?
>>
>>   
>>     
> Yes. When using a custom route (msg_route::with_route). If you make 
> optimize::cache_string_several_str<> your msg formatter.
> See http://torjo.com/log2/doc/html/no__levels__with__route_8cpp-example.html
>   

Great.

>> Second, is there any particular reason not to use shared_ptr directly?
>>
>>   
>>     
> Yes, see this : 
> http://torjo.com/log2/doc/html/namespaceboost_1_1logging_1_1manipulator.html#manipulator_manipulate
>   

That doesn't answer my question.

>> Level:   I can't figure out from the documentation what I would need to do
>>          to model this concept.
>>   
>>     
> http://torjo.com/log2/doc/html/namespaceboost_1_1logging_1_1level.html
>
> (also, see scenario below)
>   

What if I want to write my own level holder?  All that gives is a list 
of level holders
and levels that you provide.

>> Gather: What exactly are the requirements?  The docs say "a function 
>> that will
>>         gather the data - called .out()" What are the requirements on the
>>         return type?  Further in scenarios_code.html#scenarios_code_mon 
>> there
>>         is the definition void *out(const char* msg) { m_msg = msg; 
>> return this; }
>>         Is out() called implicitly or not?  Why is "this" returned as a 
>> void*?
>>         Confused...
>>   
>>     
> The requirements are to return a void* pointer.
> This is needed when http://torjo.com/log2/doc/html/caching.html and you 
> want to cache the filter as well.
>   

Then, are there two cases?  The version of out returning an ostream
and the version that processes the results directly and returns void*?

> If I remove the usage of 
> http://torjo.com/log2/doc/html/caching.html#caching_BOOST_LOG_BEFORE_INIT_CACHE_FILTER
> then you can return anything you like.
> For more details, please take a look at cache_before_init_macros.hpp, 
> line 50
>   
>> Tag: The only requirement on a tag is that it must be CopyConstructable 
>> (Is it
>>      Assignable, too?).  tag::holder is a effectively a fusion::set of tags.
>>   
>>     
> Not really - theres'a  bit of logic in that class.
>   

Ok.  That was the best guess I could come up with from
namespaceboost_1_1logging_1_1tag.html.
(structboost_1_1logging_1_1tag_1_1holder.html is completely useless)

>>      It's not clear from either the tag or holder documentation how to 
>> extract
>>      tags in a formatter.
>>   
>>     
> Not sure what you mean.
>   

Suppose I write my own tag.

struct my_tag {
   const char* data;
};

Now, I also need a formatter capable of processing it, right?
a) what should the argument type to the formatter be?
b) How do I get the value of my_tag?

>> One final comment about the Concepts:
>>
>> Manipulators: I think this framework is overly complex.  It would be 
>>   
>>     
> Why?
>   

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.

>> better to
>>               make manipulators Equality Comparable Unary Function Objects.
>>               In the case of destinations the return type is ignored, for
>>               for formatters, the result type should be the same as the 
>> argument
>>               type.  For both the argument type is determined from the 
>>   
>>     
> "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?

>> logger.
>>               You can use type erasure to allow them to be treated 
>> polymorphically
>>               at runtime.
>>   
>>     
> Isn't this what I'm doing?
>   

Maybe so, but I don't understand the need to use inheritance at all.

In Christ,
Steven Watanabe