]> git.saurik.com Git - wxWidgets.git/blob - docs/doxygen/overviews/debugging.h
Don't take the previous paragraph style when deleting paragraph marker
[wxWidgets.git] / docs / doxygen / overviews / debugging.h
1 /////////////////////////////////////////////////////////////////////////////
2 // Name: debugging.h
3 // Purpose: topic overview
4 // Author: wxWidgets team
5 // RCS-ID: $Id$
6 // Licence: wxWindows license
7 /////////////////////////////////////////////////////////////////////////////
8
9 /*!
10
11 @page overview_debugging Debugging overview
12
13 Classes, functions and macros: wxDebugContext, wxObject, wxLog,
14 @ref overview_logfunctions, @ref overview_debugmacros
15
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.
21
22
23
24 @section overview_debugging_dbgctx wxDebugContext
25
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.
29
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.
33
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.
42
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).
46
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).
51
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:
54
55 @code
56 #define new new(__FILE__,__LINE__)
57 @endcode
58
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.
64
65
66
67 @section overview_debugging_dbgmacros Debug macros
68
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.
72
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:
76
77 @code
78 void MyClass::MyFunction(wxObject* object)
79 {
80 wxASSERT_MSG( (object != NULL), "object should not be NULL in MyFunction!" );
81
82 ...
83 };
84 @endcode
85
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.
88
89
90
91 @section overview_debugging_logging Logging functions
92
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.
95
96
97
98 @section overview_debugging_dbgctx2 wxDebugContext overview
99
100 Class: wxDebugContext
101
102 wxDebugContext is a class for performing various debugging and memory tracing operations.
103
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.
110
111 Here's an example of use. The SetCheckpoint ensures that only the
112 allocations done after the checkpoint will be dumped.
113
114 @code
115 wxDebugContext::SetCheckpoint();
116
117 wxDebugContext::SetFile("c:\\temp\\debug.log");
118
119 wxString *thing = new wxString;
120
121 char *ordinaryNonObject = new char[1000];
122
123 wxDebugContext::Dump();
124 wxDebugContext::PrintStatistics();
125 @endcode
126
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.
131
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.
134
135 */
136