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

Subject: Re: [boost] [log] Boost.Log formal review
From: strasser_at_[hidden]
Date: 2010-03-08 09:12:30

Zitat von Andrey Semashev <andrey.semashev_at_[hidden]>:
>> I think(!) it wouldn't require templating the whole library on the
>> attribute set, but the filtering etc. could be instantiated on the
>> attributes passed to the logger.
>
> Attribute sets are used in loggers and the core. I don't see how it  
> would be possible not to template them if some kind of type erasure  
> is not used (which brings us to the current solution). Further, the  
> core constructs a view of attribute values out of the attribute  
> sets, which is basically a map, like attribute sets. This view is  
> then processed by filters, formatters and sinks, so they will be  
> templated, too.
>
>> I presume attributes are now stored in a std::map<std::string,Attribute>
>> or similar. this is not an acceptable performance overhead for WAL.
>
> And what is your suggestion? Use fusion::map? Or  
> std::map<std::type_info, Attribute>?

fusion::map, or not constructing a (dynamic) view of the attributes  
but passing it through.
I don't think that would mean parametrizing the core by the whole  
attribute set of every attribute ever used throughout the application,  
but it probably does mean templating the core e.g. by the filters.

>> I've asked before if binary logging is considered within the scope of
>> the library. if it turns out that it's not, I can stop reviewing it from
>> this angle at any time.
>
> Yes, it has been considered. It is possible to create a binary sink  
> that will serialize the attribute values and the message.

I understand that you can write your own sink and store the  
information in whatever way, but with most use cases of binary logging  
come several requirements, e.g. performance-wise it should be similar  
to:

http_connection_requested record(host,port);

stream.sputc( get_record_identity(record) );
stream.sputn( &record, sizeof(record) );

(assuming that the record is bitwise-serializable)

a lot of stuff that is now done at runtime, like creating a view of  
the attributes and filtering records based on that view, would have to  
be done at compile-time.

so before I write a lengthy review from that angle, that would most  
likely result in a NO vote, let me know if this is beyond the scope of  
the library.

this question is not only directed towards you but also towards other  
reviewers; if that use case is considered within the scope of a boost  
logging library.