On 02/09/2012 07:05 PM, ext [email protected] wrote: > I see. You'll indeed need something like that if you want to define > which category to log or not with the help of the macro expander.
The point here is that a disabled category adds very minimal runtime overhead. We must get to the "do nothing" case in as few instructions as possible or performance of Qt will tank (since this is supposed to facilitate logging statements being left in Qt). > You might still get half-way there performance wise though by giving > QDebug a boolean "active", and check for it in the various > operator<< Not even close. Ok... maybe if you only ever pass primitive types. Consider this though: qLog(category) << some_expensive_function(); The only way to avoid some_expensive_function() is to not execute that code path at all. Thus the macro expansion: if (do_nothing) /*NOP*/; else qDebug() << some_expensive_function(); > Anyhow, a more basic question I have is whether we want the filtering > by category be done at runtime (e.g. in a central message handler), > or at compile time (like your solution seems to be based on). Maybe > there's place for both, but I thought the idea for the Qt libraries > was to avoid the need for recompiles ... qLog is most certainly a run-time system. The actual macro looks more like this: if (!global_enabled() || !category_enabled(cat)) /*NOP*/; else qDebug() -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
