> -----Original Message----- > From: Kurt Pattyn [mailto:[email protected]] > On 08 Jan 2014, at 10:12, Koehne Kai <[email protected]> wrote: > > > > > You can then use it like that: > > > > If (qtCoreIo().isDebugEnabled()) { > > QString x = expensive(); > > qCDebug(qtCoreIo) << "Expensive: " << x; } > > > > Anyhow, note that qCDebug(qtCoreIo) expands to > > > > for (bool enabled = qtCoreIo().isDebugEnabled(); Q_UNLIKELY(enabled); > > enabled = false) QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO, > > qtCoreIo().categoryName()).debug() << > > > Out of curiosity: is there a reason you use 'for' and not an 'if' statement?
Imagine what would happen with the following code if (somethingserioushappened) qCWarning(myCategory) << "Serious issue!"; else qCDebug(myCategory) << "Everything's fine :)"; if qCWarning() would expand to an if (myCategory().isEnabled()) ... > > so this should be needed only if your 'expensive' operations aren't behind > the << anyway. > > > >> Also, what's the overhead of a qCDebug for a disabled category? Qt > >> should never emit debug warnings in its default configuration, so > >> we're talking about many hits to that. > > > > The overhead for a non-enabled qCDebug is basically a function call + one > boolean check (isDebugEnabled() will be inlined). > > > If code size or performance is a problem for certain critical code sections, > you > could also use a full macro, like: > qCDebug(category, a << b << "some string"); > > This construct looks rather strange or even ugly, but has the advantage that > it > can be completely compiled away. If you want to compile it away there's already QT_NO_DEBUG_OUTPUT, which changes the definition of qCDebug to while (false) QMessageLogger().noDebug() which I expect every compiler worth its name to optimize away :) Regards Kai _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
