[Development] Let's get rid of qDebug/qWarning/qCritical!

[Koehne Kai]

> -----Original Message-----
> From: Kurt Pattyn [mailto:kurt.pattyn at icloud.com]
> On 08 Jan 2014, at 10:12, Koehne Kai <Kai.Koehne at digia.com> 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