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

Subject: Re: [boost] [Log] Pre-review questions
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2010-03-14 17:11:41

On 14 March 2010 13:00, Andrey Semashev <andrey.semashev_at_[hidden]> wrote:

> On 03/14/2010 06:29 PM, Christian Holmquist wrote:
>
>>
>> Simple task 1
>> I've two source level attributes, System and Severity. I wish to create a
>> log macro that takes these two arguments.
>>
>
> [snip]
>
>
>  The above is not a complicated scenario and I should be able to quickly
>> find
>> an answer. Maybe I've just missed it..:)
>>
>
> Well, depending on how you use the "System" attribute, you can take either
> of the following approaches:
>
>
>
<snip>
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, our
current macro looks something like

LOG(System, SeverityLevel, Messsage) \
  if(Log::IsEnabled(System, SeverityLevel) \
  {
    Log::Record r(System, SeverityLevel, __LINE__, __FUNCTION__, timestamp,
thread-id, etc, etc..)
    r.msg << Message;
    Log::Add(r);
  }

>
>  Simple task 2
>> Create a custom filter without using any Lambda magic.
>>
>> Well, if you want to develop a filter from ground, here you go:
>
>
>
<snip>

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?

But honestly, it would be much simpler if you used the tools provided by the
> library.
> _______________________________________________
>
>
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..)

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.

/ christian