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
> 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;
if (!logging::extract< System >("System", attrs, var(sys) = _1))
throw runtime_error("System not found");
if (!logging::extract< SeverityLevel >(
"Severity", attrs, var(sev) = _1))
throw runtime_error("Severity not found");
return levels[sys] >= sev;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk