On 03/15/2010 12:11 AM, Christian Holmquist wrote:
On 14 March 2010 13:00, Andrey Semashev<andrey.semashev@gmail.com> 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; }