Re: [boost] [Log] Pre-review questions

Subject: Re: [boost] [Log] Pre-review questions
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-14 18:01:32

On 03/15/2010 12:11 AM, Christian Holmquist wrote:
> On 14 March 2010 13:00, Andrey Semashev<andrey.semashev_at_[hidden]>  wrote:
>
>> Well, depending on how you use the "System" attribute, you can take either
>> of the following approaches:
>>
> Ok. We probably about have 200 hundred named systems. Which approach would
> be most optimal in terms of compilation speed and impact on the size of the
> final executable? System and SeverityLevel must always be present

Then my third variant suits you best.

> This code looks kind of expensive to execute. Hard to tell the impact in
> reality, but it must be much heavier than using a plain old struct for the
> attributes.
> Is it out of the question to change the attributes from being a pure runtime
> configured entity, to something like a fusion::map?

It has been discussed in another thread of this review. No, fusion::map 
is not possible to be used now. And if something like it gets 
incorporated into the library, it won't be a compile-time lookup anyway.

> Ok, let me explain my usecase further.
> At runtime I want to modify the filter which controls the log output to the
> console sink.
> UpdateConsoleFilter(System, SeverityLevel)
>
> The filter will have something like array<SeverityLevel, N>, where N is
> number of 'System's.
>
> This function is exposed in the runtime command line, allowing me to write
> MyApp>  log "SystemA" "DEBUG"
> to change the behaviour of the filter during execution of the program.
>
> struct filter
> {
>    const array<SeverityLevel, NumberOfSystems>&  levels;
>    bool operator()(Attributes const&  attrs)
>    {
>      return levels[attrs["System"]]>= attrs["SeverityLevel"];
>    }
> };
>
> Since I can't retrieve the filter from a sink, the levels array is a const
> ref so that I can modify it elsewhere. (it doesn't have to be thread safe,
> since it's just assignment of integers, btw..)

Generally, that doesn't mean that it doesn't have to be thread-protected.

> I find my filter code really simple, and I don't see why I would need to
> figure out how to express this using lambda style.

To write a shorter code? Lambda functions can really help in this 
regard. For instance, my previous version could be rewritten as follows:

   result_type operator() (attribute_values_view const& attrs) const
   {
     using namespace boost::lambda;

     System sys;
     if (!logging::extract< System >("System", attrs, var(sys) = _1))
       throw runtime_error("System not found");

     SeverityLevel sev;
     if (!logging::extract< SeverityLevel >(
       "Severity", attrs, var(sev) = _1))
       throw runtime_error("Severity not found");

     return levels[sys] >= sev;
   }