]>
Commit | Line | Data |
---|---|---|
15b6757b | 1 | ///////////////////////////////////////////////////////////////////////////// |
d54cf7ff | 2 | // Name: container.h |
15b6757b FM |
3 | // Purpose: topic overview |
4 | // Author: wxWidgets team | |
5 | // RCS-ID: $Id$ | |
526954c5 | 6 | // Licence: wxWindows licence |
15b6757b FM |
7 | ///////////////////////////////////////////////////////////////////////////// |
8 | ||
880efa2a | 9 | /** |
36c9828f | 10 | |
880efa2a | 11 | @page overview_container Container Classes |
36c9828f | 12 | |
e7054054 BP |
13 | @tableofcontents |
14 | ||
7311debd VZ |
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 | ||
831e1028 BP |
47 | @see @ref group_class_containers |
48 | ||
7311debd | 49 | |
e7054054 | 50 | |
7311debd | 51 | @section overview_container_legacy Legacy Classes |
d54cf7ff | 52 | |
880efa2a BP |
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. | |
d54cf7ff | 58 | |
880efa2a BP |
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. | |
d54cf7ff | 65 | |
880efa2a | 66 | For the same portability reasons, the container classes implementation in |
7311debd VZ |
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. | |
d54cf7ff | 71 | |
880efa2a BP |
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! | |
d54cf7ff | 78 | |
880efa2a BP |
79 | As array classes never delete the items they contain anyhow, there is no |
80 | WX_DEFINE_ARRAY() macro for them. | |
d54cf7ff | 81 | |
880efa2a BP |
82 | Examples of usage of these macros may be found in wxList<T> and wxArray<T> |
83 | documentation. | |
d54cf7ff | 84 | |
880efa2a BP |
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. | |
36c9828f | 93 | |
7311debd | 94 | |
e7054054 | 95 | |
7311debd VZ |
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 | ||
d54cf7ff | 130 | */ |