/****************************************************************************
**
** Qt Debugging Techniques
**
** Copyright (C) 1992-2007 Trolltech ASA. All rights reserved.
**
** This file is part of the Qt GUI Toolkit.
** EDITIONS: FREE, PROFESSIONAL, ENTERPRISE
**
** This file is provided AS IS with NO WARRANTY OF ANY KIND, INCLUDING THE
** WARRANTY OF DESIGN, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
**
****************************************************************************/

/*!
    \page debug.html
    \title Debugging Techniques
    \ingroup buildsystem

    Here we present some useful hints to help you with debugging your
    Qt-based software.

    \tableofcontents

    \section1 Configuring Qt for Debugging

    When \l{Installation}{configuring Qt for installation}, it is possible
    to ensure that it is built to include debug symbols that can make it
    easier to track bugs in applications and libraries. However, on some
    platforms, building Qt in debug mode will cause applications to be larger
    than desirable.

    \section2 Mac OS X and Xcode

    The amount of space taken up by debug symbols generated by GCC can be
    excessively large. However, with the release of Xcode 2.3 it is now possible
    to use Dwarf symbols which take up a significantly smaller amount of space.
    To enable this feature when configuring Qt, pass the \c{-dwarf-2} option to
    the configure script.

    This is not enabled by default because previous versions of Xcode will not
    work with the compiler flag used to implement this feature. Mac OS X 10.5
    will use dwarf-2 symbols by default.

    dwarf-2 symbols contain references to source code, so the size of the final
    debug application should compare favorably to a release build.

    \omit
    Although it is not necessary to build Qt with debug symbols to use the
    other techniques described in this document, certain features are only
    available when Qt is configured for debugging.
    \endomit

    \section1 Command Line Options Recognized by Qt

    When you run a Qt application, you can specify several
    command-line options that can help with debugging. These are
    recognized by QApplication.

    \table
    \header \o Option \o Description
    \row \o \c -nograb
         \o The application should never grab \link QWidget::grabMouse()
            the mouse\endlink or \link QWidget::grabKeyboard() the
            keyboard \endlink. This option is set by default when the
            program is running in the \c gdb debugger under Linux.
    \row \o \c -dograb
         \o Ignore any implicit or explicit \c{-nograb}. \c -dograb wins over
            \c -nograb even when \c -nograb is last on the command line.
    \row \o \c -sync
         \o Runs the application in X synchronous mode. Synchronous mode
            forces the X server to perform each X client request
            immediately and not use buffer optimization. It makes the
            program easier to debug and often much slower. The \c -sync
            option is only valid for the X11 version of Qt.
    \endtable

    \section1 Warning and Debugging Messages

    Qt includes four global functions for writing out warning and debug
    text. You can use them for the following purposes:

    \list
    \o qDebug() is used for writing custom debug output.
    \o qWarning() is used to report warnings and recoverable errors in
       your application.
    \o qCritical() is used for writing critical error mesages and
       reporting system errors.
    \o qFatal() is used for writing fatal error messages shortly before exiting.
    \endlist

    If you include the <QtDebug> header file, the \c qDebug() function
    can also be used as an output stream. For example:

    \code
        qDebug() << "Widget" << widget << "at position" << widget->pos();
    \endcode

    The Qt implementation of these functions prints the text to the
    \c stderr output under Unix/X11 and Mac OS X. With Windows, if it
    is a console application, the text is sent to console; otherwise, it
    is sent to the debugger. You can take over these functions by
    installing a message handler using qInstallMsgHandler().

    If the \c QT_FATAL_WARNINGS environment variable is set,
    qWarning() exits after printing the warning message. This makes
    it easy to obtain a backtrace in the debugger.

    Both qDebug() and qWarning() are debugging tools. They can be
    compiled away by defining \c QT_NO_DEBUG_OUTPUT and \c
    QT_NO_WARNING_OUTPUT during compilation.

    The debugging functions QObject::dumpObjectTree() and
    QObject::dumpObjectInfo() are often useful when an application
    looks or acts strangely. More useful if you use \l{QObject::setObjectName()}{object names}
    than not, but often useful even without names.

    \section1 Providing Support for the qDebug() Stream Operator

    You can implement the stream operator used by qDebug() to provide
    debugging support for your classes. The class that implements the
    stream is \c QDebug. The functions you need to know about in \c
    QDebug are \c space() and \c nospace(). They both return a debug
    stream; the difference between them is whether a space is inserted
    between each item. Here is an example for a class that represents
    a 2D coordinate.

    \quotefromfile snippets/qdebugsnippet.cpp
    \skipto /QDebug/
    \printuntil /^\}/

    \section1 Debugging Macros

    The header file \c <QtGlobal> contains some debugging macros and
    \c{#define}s.

    Three important macros are:
    \list
    \o \l{Q_ASSERT()}{Q_ASSERT}(cond), where \c cond is a boolean
       expression, writes the warning "ASSERT: '\e{cond}' in file xyz.cpp, line
       234" and exits if \c cond is false.
    \o \l{Q_ASSERT_X()}{Q_ASSERT_X}(cond, where, what), where \c cond is a
       boolean expression, \c where a location, and \c what a message,
       writes the warning: "ASSERT failure in \c{where}: '\c{what}', file xyz.cpp, line 234"
       and exits if \c cond is false.
    \o \l{Q_CHECK_PTR()}{Q_CHECK_PTR}(ptr), where \c ptr is a pointer.
       Writes the warning "In file xyz.cpp, line 234: Out of memory" and
       exits if \c ptr is 0.
    \endlist

    These macros are useful for detecting program errors, e.g. like this:

    \code
        char *alloc(int size)
        {
            Q_ASSERT(size > 0);
            char *ptr = new char[size];
            Q_CHECK_PTR(ptr);
            return ptr;
        }
    \endcode

    Q_ASSERT(), Q_ASSERT_X(), and Q_CHECK_PTR() expand to nothing if
    \c QT_NO_DEBUG is defined during compilation. For this reason,
    the arguments to these macro should not have any side-effects.
    Here is an incorrect usage of Q_CHECK_PTR():

    \code
        char *alloc(int size)
        {
            char *ptr;
            Q_CHECK_PTR(ptr = new char[size]);  // WRONG
            return ptr;
        }
    \endcode

    If this code is compiled with \c QT_NO_DEBUG defined, the code in
    the Q_CHECK_PTR() expression is not executed and \e alloc returns
    an unitialized pointer.

    The Qt library contains hundreds of internal checks that will
    print warning messages when a programming error is detected. We
    therefore recommend that you use a debug version of Qt when
    developing Qt-based software.

    \section1 Common Bugs

    There is one bug that is so common that it deserves mention here:
    If you include the Q_OBJECT macro in a class declaration and
    run \link moc.html the meta-object compiler\endlink (\c{moc}),
    but forget to link the \c{moc}-generated object code into your
    executable, you will get very confusing error messages. Any link
    error complaining about a lack of \c{vtbl}, \c{_vtbl}, \c{__vtbl}
    or similar is likely to be a result of this problem.
*/
