1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
|
<HTML>
<head><title>Strategies for reducing programming errors</title></head>
<BODY BGCOLOR=#FFFFFF>
<A NAME="topic19"></A><CENTER>
<A HREF="wx.htm"><img align=center src="contents.gif" BORDER=0 ALT="Contents"></A> <A HREF="wx18.htm#strategies"><img align=center src="up.gif" BORDER=0 ALT="Up"></A> <A HREF="wx18.htm#strategies"><img align=center src="back.gif" BORDER=0 ALT="Previous"></A> <A HREF="wx20.htm#topic22"><img align=center src="forward.gif" BORDER=0 ALT="Next"></A> </CENTER><HR>
<H2>Strategies for reducing programming errors</H2>
<P>
<A HREF="#topic20">Use ASSERT</A><BR>
<A HREF="#topic21">Use wxString in preference to character arrays</A><BR>
<P>
<HR>
<A NAME="topic20"></A>
<H3>Use ASSERT</H3>
<P>
Although I haven't done this myself within wxWindows, it is good
practice to use ASSERT statements liberally, that check for conditions that
should or should not hold, and print out appropriate error messages.
These can be compiled out of a non-debugging version of wxWindows
and your application. Using ASSERT is an example of 'defensive programming':
it can alert you to problems later on.<P>
<HR>
<A NAME="topic21"></A>
<H3>Use wxString in preference to character arrays</H3>
<P>
Using wxString can be much safer and more convenient than using char *.
Again, I haven't practised what I'm preaching, but I'm now trying to use
wxString wherever possible. You can reduce the possibility of memory
leaks substantially, and it's much more convenient to use the overloaded
operators than functions such as strcmp. wxString won't add a significant
overhead to your program; the overhead is compensated for by easier
manipulation (which means less code).<P>
The same goes for other data types: use classes wherever possible.<P>
</BODY></HTML>
|
