QT_NO_DEBUG, Q_ASSERT(), and release build types

[Ingo Klöcker]

On Sunday 11 January 2009, Andreas Hartmetz wrote:
> Hi all,
>
> it occurred to me that QT_NO_DEBUG is not defined in RELWITHDEBINFO
> build mode. It is defined, since Allen Winter made it so, in RELEASE
> build mode. Note that Debian packages and probably others are built
> with RELWITHDEBINFO, then the debug symbols are stripped and packaged
> separately. Unfortunately QT_NO_DEBUG has several effects. One of
> them is to no-op qDebug(), another is to no-op Q_ASSERT(). Its
> absence also enables things like bounds checking in QList accessors
> which is obviously detrimental to performance, even though compilers
> should be able to optimize away the checks in loops.
> Q_ASSERT() is *documented* to be a debugging help, and in my
> not-so-humble opinion it should be used like that. There are
> conditions that should never go unnoticed while debugging but
> nevertheless shouldn't crash for users. Even a memory leak is better
> than potentially losing data.
> For really unrecoverable errors some to be defined CRASH_ON() or
> BUG_ON() macro should be used IMO.
> I think that QT_NO_DEBUG should be enabled for RELWITHDEBINFO as
> well, and if that is not feasible we should look into disabling only
> asserts and checks; I don't know how to do that though.
> We probably also want to keep kDebug() output enabled even in release
> builds...

I don't think keeping kDebug() enabled in release builds is a good idea 
because of highly likely performance problems. At least, not if logging 
kDebug() messages is turned on by default. If logging of debug messages 
was enabled but turned off by default and could easily be turned on by 
the user if necessary (e.g. through kdebugdialog) then I would agree 
that enabling it even in release builds would probably be a good idea.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090112/cf3f539c/attachment.sig>