]>
git.saurik.com Git - wxWidgets.git/blob - docs/doxygen/overviews/debugging.h
fbac7ff7c7cdb62a8b1b43048ffe479a496e7e8c
   1 ///////////////////////////////////////////////////////////////////////////// 
   3 // Purpose:     topic overview 
   4 // Author:      wxWidgets team 
   6 // Licence:     wxWindows license 
   7 ///////////////////////////////////////////////////////////////////////////// 
  11  @page overview_debugging Debugging overview 
  13  Classes, functions and macros: #wxDebugContext, #wxObject, #wxLog, 
  14  @ref overview_logfunctions, @ref overview_debugmacros 
  16  Various classes, functions and macros are provided in wxWidgets to help you debug 
  17  your application. Most of these are only available if you compile both wxWidgets, 
  18  your application and @e all libraries that use wxWidgets with the __WXDEBUG__ symbol 
  19  defined. You can also test the __WXDEBUG__ symbol in your own applications to execute 
  20  code that should be active only in debug mode. 
  24  @section overview_debugging_dbgctx wxDebugContext 
  26  #wxDebugContext is a class that never gets instantiated, but ties together 
  27  various static functions and variables. It allows you to dump all objects to that stream,  
  28  write statistics about object allocation, and check memory for errors. 
  30  It is good practice to define a wxObject::Dump member function for each class you derive 
  31  from a wxWidgets class, so that wxDebugContext::Dump can call it and 
  32  give valuable information about the state of the application. 
  34  If you have difficulty tracking down a memory leak, recompile 
  35  in debugging mode and call wxDebugContext::Dump and wxDebugContext::PrintStatistics at 
  36  appropriate places. They will tell you what objects have not yet been 
  37  deleted, and what kinds of object they are. In fact, in debug mode wxWidgets will automatically 
  38  detect memory leaks when your application is about to exit, and if there are any leaks, 
  39  will give you information about the problem. (How much information depends on the operating system 
  40  and compiler -- some systems don't allow all memory logging to be enabled). See the 
  41  memcheck sample for example of usage. 
  43  For wxDebugContext to do its work, the @e new and @e delete operators for wxObject  
  44  have been redefined to store extra information about dynamically allocated objects  
  45  (but not statically declared objects).  
  47  This slows down a debugging version of an application, but can 
  48  find difficult-to-detect memory leaks (objects are not 
  49  deallocated), overwrites (writing past the end of your object) and 
  50  underwrites (writing to memory in front of the object). 
  52  If debugging mode is on and the symbols wxUSE_GLOBAL_MEMORY_OPERATORS and 
  53  wxUSE_DEBUG_NEW_ALWAYS are set to 1 in setup.h, 'new' is defined to be: 
  56  #define new new(__FILE__,__LINE__) 
  59  All occurrences of 'new' in wxWidgets and your own application will use 
  60  the overridden form of the operator with two extra arguments. This means that  
  61  the debugging output (and error messages reporting memory problems) will tell you what 
  62  file and on what line you allocated the object. Unfortunately not all 
  63  compilers allow this definition to work properly, but most do. 
  67  @section overview_debugging_dbgmacros Debug macros 
  69  You should also use @ref debugmacros_overview as part of a 'defensive programming' strategy, 
  70  scattering wxASSERTs liberally to test for problems in your code as early as possible. 
  71  Forward thinking will save a surprising amount of time in the long run. 
  73  #wxASSERT is used to pop up an error message box when a condition 
  74  is not @true. You can also use #wxASSERT_MSG to supply your 
  75  own helpful error message. For example: 
  78    void MyClass::MyFunction(wxObject* object) 
  80        wxASSERT_MSG( (object != NULL), "object should not be NULL in MyFunction!" ); 
  86  The message box allows you to continue execution or abort the program. If you are running 
  87  the application inside a debugger, you will be able to see exactly where the problem was. 
  91  @section overview_debugging_logging Logging functions 
  93  You can use the #wxLogDebug and #wxLogTrace functions to output debugging information in  
  94  debug mode; it will do nothing for non-debugging code. 
  98  @section overview_debugging_dbgctx2 wxDebugContext overview 
 100  Class: #wxDebugContext 
 102  wxDebugContext is a class for performing various debugging and memory tracing operations. 
 104  This class has only static data and function members, and there should be 
 105  no instances. Probably the most useful members are SetFile (for directing output 
 106  to a file, instead of the default standard error or debugger output); 
 107  Dump (for dumping the dynamically allocated objects) and PrintStatistics 
 108  (for dumping information about allocation of objects). You can also call 
 109  Check to check memory blocks for integrity. 
 111  Here's an example of use. The SetCheckpoint ensures that only the 
 112  allocations done after the checkpoint will be dumped. 
 115    wxDebugContext::SetCheckpoint(); 
 117    wxDebugContext::SetFile("c:\\temp\\debug.log"); 
 119    wxString *thing = new wxString; 
 121    char *ordinaryNonObject = new char[1000]; 
 123    wxDebugContext::Dump(); 
 124    wxDebugContext::PrintStatistics(); 
 127  You can use wxDebugContext if __WXDEBUG__ is defined, or you can use it 
 128  at any other time (if wxUSE_DEBUG_CONTEXT is set to 1 in setup.h). It is not disabled 
 129  in non-debug mode because you may not wish to recompile wxWidgets and your entire application 
 130  just to make use of the error logging facility. 
 132  @note wxDebugContext::SetFile has a problem at present, so use the default stream instead. 
 133        Eventually the logging will be done through the wxLog facilities instead.