]>
Commit | Line | Data |
---|---|---|
1 | ///////////////////////////////////////////////////////////////////////////// | |
2 | // Name: container.h | |
3 | // Purpose: topic overview | |
4 | // Author: wxWidgets team | |
5 | // RCS-ID: $Id$ | |
6 | // Licence: wxWindows licence | |
7 | ///////////////////////////////////////////////////////////////////////////// | |
8 | ||
9 | /** | |
10 | ||
11 | @page overview_container Container Classes | |
12 | ||
13 | @tableofcontents | |
14 | ||
15 | For historical reasons, wxWidgets uses custom container classes internally. | |
16 | This was unfortunately unavoidable during a long time when the standard library | |
17 | wasn't widely available and can't be easily changed even now that it is for | |
18 | compatibility reasons. If you are building your own version of the library and | |
19 | don't care about compatibility nor slight (less than 5%) size penalty imposed | |
20 | by the use of STL classes, you may choose to use the "STL" build of wxWidgets | |
21 | in which these custom classes are replaced with their standard counterparts and | |
22 | only read the section @ref overview_container_std explaining how to do it. | |
23 | ||
24 | Otherwise you will need to know about the custom wxWidgets container classes | |
25 | such as wxList<T> and wxArray<T> if only to use wxWidgets functions that work | |
26 | with them, e.g. wxWindow::GetChildren(), and you should find the information | |
27 | about using these classes below useful. | |
28 | ||
29 | Notice that we recommend that you use standard classes directly in your own | |
30 | code instead of the container classes provided by wxWidgets in any case as the | |
31 | standard classes are easier to use and may also be safer because of extra | |
32 | run-time checks they may perform as well as more efficient. | |
33 | ||
34 | Finally notice that recent versions of wxWidgets also provide standard-like | |
35 | classes such as wxVector<T>, wxStack<T> or wxDList which can be used exactly | |
36 | like the std::vector<T>, std::stack<T> and std::list<T*>, respectively, and | |
37 | actually are just typedefs for the corresponding types if wxWidgets is compiled | |
38 | in STL mode. These classes could be useful if you wish to avoid the use of the | |
39 | standard library in your code for some reason. | |
40 | ||
41 | To summarize, you should use the standard container classes such as | |
42 | std::vector<T> and std::list<T> if possible and wxVector<T> or wxDList<T> if | |
43 | it isn't and only use legacy wxWidgets containers such as wxArray<T> and | |
44 | wxList<T> when you must, i.e. when you use a wxWidgets function taking or | |
45 | returning a container of such type. | |
46 | ||
47 | @see @ref group_class_containers | |
48 | ||
49 | ||
50 | ||
51 | @section overview_container_legacy Legacy Classes | |
52 | ||
53 | The list classes in wxWidgets are doubly-linked lists which may either own the | |
54 | objects they contain (meaning that the list deletes the object when it is | |
55 | removed from the list or the list itself is destroyed) or just store the | |
56 | pointers depending on whether or not you called wxList<T>::DeleteContents() | |
57 | method. | |
58 | ||
59 | Dynamic arrays resemble C arrays but with two important differences: they | |
60 | provide run-time range checking in debug builds and they automatically expand | |
61 | the allocated memory when there is no more space for new items. They come in | |
62 | two sorts: the "plain" arrays which store either built-in types such as "char", | |
63 | "int" or "bool" or the pointers to arbitrary objects, or "object arrays" which | |
64 | own the object pointers to which they store. | |
65 | ||
66 | For the same portability reasons, the container classes implementation in | |
67 | wxWidgets don't use templates, but are rather based on C preprocessor i.e. are | |
68 | implemented using the macros: WX_DECLARE_LIST() and WX_DEFINE_LIST() for the | |
69 | linked lists and WX_DECLARE_ARRAY(), WX_DECLARE_OBJARRAY() and | |
70 | WX_DEFINE_OBJARRAY() for the dynamic arrays. | |
71 | ||
72 | The "DECLARE" macro declares a new container class containing the elements of | |
73 | given type and is needed for all three types of container classes: lists, | |
74 | arrays and objarrays. The "DEFINE" classes must be inserted in your program in | |
75 | a place where the @e full declaration of container element class is in scope | |
76 | (i.e. not just forward declaration), otherwise destructors of the container | |
77 | elements will not be called! | |
78 | ||
79 | As array classes never delete the items they contain anyhow, there is no | |
80 | WX_DEFINE_ARRAY() macro for them. | |
81 | ||
82 | Examples of usage of these macros may be found in wxList<T> and wxArray<T> | |
83 | documentation. | |
84 | ||
85 | Finally, wxWidgets predefines several commonly used container classes. wxList | |
86 | is defined for compatibility with previous versions as a list containing | |
87 | wxObjects and wxStringList as a list of C-style strings (char *), both of these | |
88 | classes are deprecated and should not be used in new programs. The following | |
89 | array classes are defined: wxArrayInt, wxArrayLong, wxArrayPtrVoid and | |
90 | wxArrayString. The first three store elements of corresponding types, but | |
91 | wxArrayString is somewhat special: it is an optimized version of wxArray which | |
92 | uses its knowledge about wxString reference counting schema. | |
93 | ||
94 | ||
95 | ||
96 | @section overview_container_std STL Build | |
97 | ||
98 | To build wxWidgets with the standard containers you need to set | |
99 | wxUSE_STD_CONTAINERS option to 1 in @c wx/msw/setup.h for wxMSW builds or | |
100 | specify @c --enable-std_containers option to configure (which is also | |
101 | implicitly enabled by @c --enable-stl option) in Unix builds. | |
102 | ||
103 | The standard container build is mostly, but not quite, compatible with the | |
104 | default one. Here are the most important differences: | |
105 | - wxList::compatibility_iterator must be used instead of wxList::Node* when | |
106 | iterating over the list contents. The compatibility_iterator class has the | |
107 | same semantics as a Node pointer but it is an object and not a pointer, so | |
108 | you need to write | |
109 | @code | |
110 | for ( wxWindowList::compatibility_iterator it = list.GetFirst(); | |
111 | it; | |
112 | it = it->GetNext() ) | |
113 | ... | |
114 | @endcode | |
115 | instead of the old | |
116 | @code | |
117 | for ( wxWindowList::Node *n = list.GetFirst(); n; n = n->GetNext() ) | |
118 | ... | |
119 | @endcode | |
120 | - wxSortedArrayString and wxArrayString are separate classes now and the | |
121 | former doesn't derive from the latter. If you need to convert a sorted array | |
122 | to a normal one, you must copy all the elements. Alternatively, you may | |
123 | avoid the use of wxSortedArrayString by using a normal array and calling its | |
124 | Sort() method when needed. | |
125 | - WX_DEFINE_ARRAY_INT(bool) cannot be used because of the differences in | |
126 | std::vector<bool> specialization compared with the generic std::vector<> | |
127 | class. Please either use std::vector<bool> directly or use an integer array | |
128 | instead. | |
129 | ||
130 | */ |