Re: [boost] [log] Boost.Log formal review closing down

Subject: Re: [boost] [log] Boost.Log formal review closing down
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-03-17 18:07:44

----- Original Message ----- 
From: "Andrey Semashev" <andrey.semashev_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, March 17, 2010 10:48 PM
Subject: Re: [boost] [log] Boost.Log formal review closing down

> 
> On 03/18/2010 12:32 AM, vicente.botet wrote:
>>>    void my_formatter(std::ostream&  strm, logging::record const&  rec)
>>>    {
>>>      logging::extract<  unsigned int>("LineID", rec.attribute_values(),
>>>        lambda::var(strm)<<  lambda::_1<<  ": ");
>>>
>>>      logging::extract<  severity_level>(
>>>        "Severity",
>>>        rec.attribute_values(),
>>>        lambda::var(strm)<<  "<"<<  lambda::_1<<  ">  ");
>>>
>>>      strm<<  rec.message();
>>>    }
>>
>>
>> Sorry I find this yet clearer
>>
>> void my_formatter(std::ostream&  strm, logging::record const&  rec)
>>    fmt::stream
>>      <<  attr<  unsigned int>("LineID")
>>      <<  ":<"<<  attr<  logging::severity_level>("Severity")
>>      <<  ">  "<<  message()
>> }
> 
> Then the current lambda syntax is your friend.

My bad. I did the bad copy/past

  fmt::stream << rec.line_id() << ": <" << rec.severity_level() << "> " << rec.message()

Could you show me this with your lambdas? 

>>>> *Attributes:
>>>> I don't like that std::string is used as attribute key. I suspect that this is not the more efficient way to have dynamics attributes.
>>>> I would prefer the library manage several kinds of attributes.
>>>>
>>>> Some attributes could be identified staticaly using a tag.
>>>>
>>>> tagged_attr<   unsigned int, tag_severity>
>>>>
>>>> Others using a std::string key
>>>>
>>>> named_attr<   unsigned int>("id")
>>>>
>>>> and others using an int index
>>>>
>>>> index_attr<   unsigned int>(3)
>>>>
>>>> The mapping could be done at two levels:
>>>> The first level maps&type_info, to either the value_type extractor.
>>>> - For tagged attributes the extractor is able to get the attribute value directly.
>>>> - For named attributes and index attributes the extractor needs the additional name or index information to get attribute value.
>>>
>>> That would complicate the library, both in terms of usage and
>>> implementation. I'd rather not introduce several different interfaces
>>> for the same thing.
>>
>> I don't know if this will complicate or not your library. One thing is clear, accessing attributes by using string is expensive, and the user expects the best performance. If your library doesn't respond to this request, your library will not be used at the end.
> 
> You keep talking of performance and something being expensive. Do you 
> have specific requirements, or have you tried the library in an actual 
> project and faced the problem? Because the tests that were mentioned 
> during the discussion show that the current approach is not slower than 
> other libraries that don't have attributes at all.

I don't need to make a test to see that looking on a map of strings is much more expensive than access a staticaly binded field (which is possible with the tag interface). Am I missing something?

>> My proposal was multiple to respond to the needs of other users. From my side it is enough to identify an attribute using a tag. What is wrong using tags?
> 
> I think, using tags as keys in the attribute set is less natural than 
> strings or any other runtime object for that matter.

Note that tags are static. So no runtime penality.
 
>>> The attribute
>>> may also be useful if log records are sent to a remote process, which
>>> may accumulate logs from a group of processes.
>>
>> May be useful, but current there is no backend sending log recods remotely.
> 
> Syslog does this. In a way, Event log does this, too. Anyway, it doesn't 
> mean the attribute should not be in the library.

You are right. This is not a reason to don't include it, but neither a reason to include it.
Could you answer my question, What is the value of "ProcessId"?

Vicente