git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@1015 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
		
			
				
	
	
		
			123 lines
		
	
	
		
			5.4 KiB
		
	
	
	
		
			TeX
		
	
	
	
	
	
			
		
		
	
	
			123 lines
		
	
	
		
			5.4 KiB
		
	
	
	
		
			TeX
		
	
	
	
	
	
\section{Debugging overview}\label{debuggingoverview}
 | 
						|
 | 
						|
Classes, functions and macros: \helpref{wxDebugContext}{wxdebugcontext}, \helpref{wxObject}{wxobject}, \helpref{wxLog}{wxlog},
 | 
						|
\rtfsp\helpref{Log functions}{logfunctions}, \helpref{Debug macros}{debugmacros}
 | 
						|
 | 
						|
Various classes, functions and macros are provided in wxWindows to help you debug
 | 
						|
your application. Most of these are only available if you compile both wxWindows,
 | 
						|
your application and {\it all} libraries that use wxWindows with the \_\_WXDEBUG\_\_ symbol
 | 
						|
defined. You can also test the \_\_WXDEBUG\_\_ symbol in your own applications to execute
 | 
						|
code that should be active only in debug mode.
 | 
						|
 | 
						|
\wxheading{wxDebugContext}
 | 
						|
 | 
						|
\helpref{wxDebugContext}{wxdebugcontext} is a class that never gets instantiated, but ties together
 | 
						|
various static functions and variables. It allows you to dump all objects to that stream, write statistics about object allocation, and
 | 
						|
check memory for errors.
 | 
						|
 | 
						|
It is good practice to define a \helpref{wxObject::Dump}{wxobjectdump} member function for each class you derive
 | 
						|
from a wxWindows class, so that \helpref{wxDebugContext::Dump}{wxdebugcontextdump} can call it and
 | 
						|
give valuable information about the state of the application.
 | 
						|
 | 
						|
If you have difficulty tracking down a memory leak, recompile
 | 
						|
in debugging mode and call \helpref{wxDebugContext::Dump}{wxdebugcontextdump} and \helpref{wxDebugContext::PrintStatistics}{wxdebugcontextprintstatistics} at
 | 
						|
appropriate places. They will tell you what objects have not yet been
 | 
						|
deleted, and what kinds of object they are. In fact, in debug mode wxWindows will automatically
 | 
						|
detect memory leaks when your application is about to exit, and if there are any leaks,
 | 
						|
will give you information about the problem. (How much information depends on the operating system
 | 
						|
and compiler -- some systems don't allow all memory logging to be enabled). See the
 | 
						|
memcheck sample for example of usage.
 | 
						|
 | 
						|
For wxDebugContext to do its work, the {\it new} and {\it delete}\rtfsp
 | 
						|
operators for wxObject have been redefined to store extra information
 | 
						|
about dynamically allocated objects (but not statically declared
 | 
						|
objects). This slows down a debugging version of an application, but can
 | 
						|
find difficult-to-detect memory leaks (objects are not
 | 
						|
deallocated), overwrites (writing past the end of your object) and
 | 
						|
underwrites (writing to memory in front of the object).
 | 
						|
 | 
						|
If debugging mode is on and the symbol wxUSE\_GLOBAL\_MEMORY\_OPERATORS is set
 | 
						|
to 1 in setup.h, 'new' is defined to be:
 | 
						|
 | 
						|
{\small
 | 
						|
\begin{verbatim}
 | 
						|
#define new new(__FILE__,__LINE__)
 | 
						|
\end{verbatim}
 | 
						|
}%
 | 
						|
 | 
						|
All occurrences of 'new' in wxWindows and your own application will use
 | 
						|
the overridden form of the operator with two extra arguments. This means that the debugging
 | 
						|
output (and error messages reporting memory problems) will tell you what
 | 
						|
file and on what line you allocated the object. Unfortunately not all
 | 
						|
compilers allow this definition to work properly, but most do.
 | 
						|
 | 
						|
\wxheading{Debug macros}
 | 
						|
 | 
						|
You should also use \helpref{debug macros}{debugmacros} as part of a `defensive programming' strategy,
 | 
						|
scattering wxASSERTs liberally to test for problems in your code as early as possible. Forward thinking
 | 
						|
will save a surprising amount of time in the long run.
 | 
						|
 | 
						|
\helpref{wxASSERT}{wxassert} is used to pop up an error message box when a condition
 | 
						|
is not true. You can also use \helpref{wxASSERT\_MSG}{wxassertmsg} to supply your
 | 
						|
own helpful error message. For example:
 | 
						|
 | 
						|
{\small
 | 
						|
\begin{verbatim}
 | 
						|
  void MyClass::MyFunction(wxObject* object)
 | 
						|
  {
 | 
						|
      wxASSERT_MSG( (object != NULL), "object should not be NULL in MyFunction!" );
 | 
						|
 | 
						|
      ...
 | 
						|
  };
 | 
						|
\end{verbatim}
 | 
						|
}
 | 
						|
 | 
						|
The message box allows you to continue execution or abort the program. If you are running
 | 
						|
the application inside a debugger, you will be able to see exactly where the problem was.
 | 
						|
 | 
						|
\wxheading{Logging functions}
 | 
						|
 | 
						|
You can use the \helpref{wxLogDebug}{wxlogdebug} and \helpref{wxLogTrace}{wxlogtrace} functions to output debugging information in debug mode;
 | 
						|
it will do nothing for non-debugging code.
 | 
						|
 | 
						|
\subsection{wxDebugContext overview}\label{wxdebugcontextoverview}
 | 
						|
 | 
						|
\overview{Debugging overview}{debuggingoverview}
 | 
						|
 | 
						|
Class: \helpref{wxDebugContext}{wxdebugcontext}
 | 
						|
 | 
						|
wxDebugContext is a class for performing various debugging and memory tracing
 | 
						|
operations.
 | 
						|
 | 
						|
This class has only static data and function members, and there should be
 | 
						|
no instances. Probably the most useful members are SetFile (for directing output
 | 
						|
to a file, instead of the default standard error or debugger output);
 | 
						|
Dump (for dumping the dynamically allocated objects) and PrintStatistics
 | 
						|
(for dumping information about allocation of objects). You can also call
 | 
						|
Check to check memory blocks for integrity.
 | 
						|
 | 
						|
Here's an example of use. The SetCheckpoint ensures that only the
 | 
						|
allocations done after the checkpoint will be dumped.
 | 
						|
 | 
						|
\begin{verbatim}
 | 
						|
  wxDebugContext::SetCheckpoint();
 | 
						|
 | 
						|
  wxDebugContext::SetFile("c:\\temp\\debug.log");
 | 
						|
 | 
						|
  wxString *thing = new wxString;
 | 
						|
 | 
						|
  char *ordinaryNonObject = new char[1000];
 | 
						|
 | 
						|
  wxDebugContext::Dump();
 | 
						|
  wxDebugContext::PrintStatistics();
 | 
						|
\end{verbatim}
 | 
						|
 | 
						|
You can use wxDebugContext if \_\_WXDEBUG\_\_ is defined, or you can use it
 | 
						|
at any other time (if wxUSE\_DEBUG\_CONTEXT is set to 1 in setup.h). It is not disabled
 | 
						|
in non-debug mode because you may not wish to recompile wxWindows and your entire application
 | 
						|
just to make use of the error logging facility.
 | 
						|
 | 
						|
Note: wxDebugContext::SetFile has a problem at present, so use the default stream instead.
 | 
						|
Eventually the logging will be done through the wxLog facilities instead.
 | 
						|
 |