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

Subject: Re: [boost] [log] Boost.Log formal review closing down
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-17 17:48:25

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.

>>> *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.

> 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.

>> 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.