Home | All Classes | Main Classes | Annotated | Grouped Classes | Functions

Debugging Techniques

Here we present some useful hints to debugging your TQt-based software.

Command Line Options

When you run a TQt program you can specify several command line options that can help with debugging.

Warning and Debugging Messages

TQt includes three global functions for writing out warning and debug text.

• qDebug() for writing debug output for testing etc.
• qWarning() for writing warning output when program errors occur.
• qFatal() for writing fatal error messages and exiting.

The TQt implementation of these functions prints the text to the stderr output under Unix/X11 and to the debugger under Windows. You can take over these functions by installing a message handler; qInstallMsgHandler().

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

Debugging Macros

The header file ntqglobal.h contains many debugging macros and #defines.

Two important macros are:

• Q_ASSERT(b) where b is a boolean expression, writes the warning: "ASSERT: 'b' in file file.cpp (234)" if b is FALSE.
• TQ_CHECK_PTR(p) where p is a pointer. Writes the warning "In file file.cpp, line 234: Out of memory" if p is 0.

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

  char *alloc( int size )
  {
      Q_ASSERT( size > 0 );
      char *p = new char[size];
      TQ_CHECK_PTR( p );
      return p;
  }

If you define the flag QT_FATAL_ASSERT, Q_ASSERT will call fatal() instead of warning(), so a failed assertion will cause the program to exit after printing the error message.

Note that the Q_ASSERT macro is a null expression if QT_CHECK_STATE (see below) is not defined. Any code in it will simply not be executed. Similarly TQ_CHECK_PTR is a null expression if QT_CHECK_NULL is not defined. Here is an example of how you should not use Q_ASSERT and TQ_CHECK_PTR:

  char *alloc( int size )
  {
      char *p;
      TQ_CHECK_PTR( p = new char[size] ); // WRONG!
      return p;
  }

The problem is tricky: p is set to a sane value only as long as the correct checking flags are defined. If this code is compiled without the QT_CHECK_NULL flag defined, the code in the TQ_CHECK_PTR expression is not executed (correctly, since it's only a debugging aid) and alloc returns a wild pointer.

The TQt library contains hundreds of internal checks that will print warning messages when some error is detected.

The tests for sanity and the resulting warning messages inside TQt are conditional, based on the state of various debugging flags:

By default, both QT_DEBUG and all the QT_CHECK flags are on. To turn off QT_DEBUG, define QT_NO_DEBUG. To turn off the QT_CHECK flags, define QT_NO_CHECK.

Example:

  void f( char *p, int i )
  {
  #if defined(QT_CHECK_NULL)
      if ( p == 0 )
          qWarning( "f: Null pointer not allowed" );
  #endif

  #if defined(QT_CHECK_RANGE)
      if ( i < 0 )
          qWarning( "f: The index cannot be negative" );
  #endif
  }

Common bugs

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