QT_NO_DEBUG, Q_ASSERT(), and release build types
Andreas Hartmetz
ahartmetz at gmail.com
Sat Jan 24 20:37:03 GMT 2009
On Monday 12 January 2009 00:15:26 Ingo Klöcker wrote:
> 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.
>
Committed like that, revision 916186.
You can see the whole diff here:
http://mercurial.intuxication.org/hg/kdelibs/rev/287994f46c5d
More information about the kde-core-devel
mailing list