]>
Commit | Line | Data |
---|---|---|
23324ae1 FM |
1 | ///////////////////////////////////////////////////////////////////////////// |
2 | // Name: dynarray.h | |
e54c96f1 | 3 | // Purpose: interface of wxArray<T> |
23324ae1 FM |
4 | // Author: wxWidgets team |
5 | // RCS-ID: $Id$ | |
6 | // Licence: wxWindows license | |
7 | ///////////////////////////////////////////////////////////////////////////// | |
8 | ||
9 | /** | |
23324ae1 | 10 | @wxheader{dynarray.h} |
7c913512 | 11 | |
23324ae1 FM |
12 | This section describes the so called @e dynamic arrays. This is a C |
13 | array-like type safe data structure i.e. the member access time is constant | |
14 | (and not | |
15 | linear according to the number of container elements as for linked lists). | |
16 | However, these | |
17 | arrays are dynamic in the sense that they will automatically allocate more | |
18 | memory if there is not enough of it for adding a new element. They also perform | |
19 | range checking on the index values but in debug mode only, so please be sure to | |
20 | compile your application in debug mode to use it (see @ref | |
21 | overview_debuggingoverview "debugging overview" for | |
22 | details). So, unlike the arrays in some other | |
23 | languages, attempt to access an element beyond the arrays bound doesn't | |
24 | automatically expand the array but provokes an assertion failure instead in | |
25 | debug build and does nothing (except possibly crashing your program) in the | |
26 | release build. | |
7c913512 | 27 | |
23324ae1 FM |
28 | The array classes were designed to be reasonably efficient, both in terms of |
29 | run-time speed and memory consumption and the executable size. The speed of | |
30 | array item access is, of course, constant (independent of the number of | |
31 | elements) | |
32 | making them much more efficient than linked lists (wxList). | |
33 | Adding items to the arrays is also implemented in more or less constant time - | |
34 | but the price is preallocating the memory in advance. In the @ref | |
35 | wxArray::memorymanagement "memory management" section | |
36 | you may find some useful hints about optimizing wxArray memory usage. As for | |
37 | executable size, all | |
38 | wxArray functions are inline, so they do not take @e any space at all. | |
7c913512 | 39 | |
23324ae1 FM |
40 | wxWidgets has three different kinds of array. All of them derive from |
41 | wxBaseArray class which works with untyped data and can not be used directly. | |
42 | The standard macros WX_DEFINE_ARRAY(), WX_DEFINE_SORTED_ARRAY() and | |
43 | WX_DEFINE_OBJARRAY() are used to define a new class deriving from it. The | |
44 | classes declared will be called in this documentation wxArray, wxSortedArray and | |
45 | wxObjArray but you should keep in mind that no classes with such names actually | |
46 | exist, each time you use one of WX_DEFINE_XXXARRAY macro you define a class | |
47 | with a new name. In fact, these names are "template" names and each usage of one | |
48 | of the macros mentioned above creates a template specialization for the given | |
49 | element type. | |
7c913512 | 50 | |
23324ae1 FM |
51 | wxArray is suitable for storing integer types and pointers which it does not |
52 | treat as objects in any way, i.e. the element pointed to by the pointer is not | |
53 | deleted when the element is removed from the array. It should be noted that | |
54 | all of wxArray's functions are inline, so it costs strictly nothing to define as | |
55 | many array types as you want (either in terms of the executable size or the | |
56 | speed) as long as at least one of them is defined and this is always the case | |
57 | because wxArrays are used by wxWidgets internally. This class has one serious | |
58 | limitation: it can only be used for storing integral types (bool, char, short, | |
59 | int, long and their unsigned variants) or pointers (of any kind). An attempt | |
60 | to use with objects of sizeof() greater than sizeof(long) will provoke a | |
61 | runtime assertion failure, however declaring a wxArray of floats will not (on | |
62 | the machines where sizeof(float) = sizeof(long)), yet it will @b not work, | |
63 | please use wxObjArray for storing floats and doubles. | |
7c913512 | 64 | |
23324ae1 FM |
65 | wxSortedArray is a wxArray variant which should be used when searching in the |
66 | array is a frequently used operation. It requires you to define an additional | |
67 | function for comparing two elements of the array element type and always stores | |
68 | its items in the sorted order (according to this function). Thus, it is | |
69 | wxArray::Index function execution time is O(log(N)) instead of | |
70 | O(N) for the usual arrays but the wxArray::Add method is | |
71 | slower: it is O(log(N)) instead of constant time (neglecting time spent in | |
72 | memory allocation routine). However, in a usual situation elements are added to | |
73 | an array much less often than searched inside it, so wxSortedArray may lead to | |
74 | huge performance improvements compared to wxArray. Finally, it should be | |
75 | noticed that, as wxArray, wxSortedArray can be only used for storing integral | |
76 | types or pointers. | |
7c913512 | 77 | |
23324ae1 FM |
78 | wxObjArray class treats its elements like "objects". It may delete them when |
79 | they are removed from the array (invoking the correct destructor) and copies | |
80 | them using the objects copy constructor. In order to implement this behaviour | |
81 | the definition of the wxObjArray arrays is split in two parts: first, you should | |
82 | declare the new wxObjArray class using WX_DECLARE_OBJARRAY() macro and then | |
83 | you must include the file defining the implementation of template type: | |
84 | wx/arrimpl.cpp and define the array class with WX_DEFINE_OBJARRAY() macro | |
85 | from a point where the full (as opposed to 'forward') declaration of the array | |
86 | elements class is in scope. As it probably sounds very complicated here is an | |
87 | example: | |
7c913512 | 88 | |
23324ae1 FM |
89 | @code |
90 | #include wx/dynarray.h | |
7c913512 | 91 | |
23324ae1 FM |
92 | // we must forward declare the array because it is used inside the class |
93 | // declaration | |
94 | class MyDirectory; | |
95 | class MyFile; | |
7c913512 | 96 | |
23324ae1 FM |
97 | // this defines two new types: ArrayOfDirectories and ArrayOfFiles which can be |
98 | // now used as shown below | |
99 | WX_DECLARE_OBJARRAY(MyDirectory, ArrayOfDirectories); | |
100 | WX_DECLARE_OBJARRAY(MyFile, ArrayOfFiles); | |
7c913512 | 101 | |
23324ae1 FM |
102 | class MyDirectory |
103 | { | |
104 | ... | |
105 | ArrayOfDirectories m_subdirectories; // all subdirectories | |
106 | ArrayOfFiles m_files; // all files in this directory | |
107 | }; | |
7c913512 | 108 | |
23324ae1 | 109 | ... |
7c913512 | 110 | |
23324ae1 FM |
111 | // now that we have MyDirectory declaration in scope we may finish the |
112 | // definition of ArrayOfDirectories -- note that this expands into some C++ | |
113 | // code and so should only be compiled once (i.e., don't put this in the | |
114 | // header, but into a source file or you will get linking errors) | |
115 | #include wx/arrimpl.cpp // this is a magic incantation which must be done! | |
116 | WX_DEFINE_OBJARRAY(ArrayOfDirectories); | |
7c913512 | 117 | |
23324ae1 FM |
118 | // that's all! |
119 | @endcode | |
7c913512 | 120 | |
23324ae1 | 121 | It is not as elegant as writing |
7c913512 | 122 | |
23324ae1 FM |
123 | @code |
124 | typedef std::vectorMyDirectory ArrayOfDirectories; | |
125 | @endcode | |
7c913512 | 126 | |
23324ae1 FM |
127 | but is not that complicated and allows the code to be compiled with any, however |
128 | dumb, C++ compiler in the world. | |
7c913512 FM |
129 | |
130 | Remember to include wx/arrimpl.cpp just before each WX_DEFINE_OBJARRAY | |
23324ae1 | 131 | ocurrence in your code, even if you have several in the same file. |
7c913512 | 132 | |
23324ae1 FM |
133 | Things are much simpler for wxArray and wxSortedArray however: it is enough |
134 | just to write | |
7c913512 | 135 | |
23324ae1 FM |
136 | @code |
137 | WX_DEFINE_ARRAY_INT(int, ArrayOfInts); | |
138 | WX_DEFINE_SORTED_ARRAY_INT(int, ArrayOfSortedInts); | |
139 | @endcode | |
7c913512 | 140 | |
23324ae1 | 141 | i.e. there is only one @c DEFINE macro and no need for separate |
7c913512 | 142 | @c DECLARE one. For the arrays of the primitive types, the macros |
23324ae1 FM |
143 | @c WX_DEFINE_ARRAY_CHAR/SHORT/INT/SIZE_T/LONG/DOUBLE should be used |
144 | depending on the sizeof of the values (notice that storing values of smaller | |
145 | type, e.g. shorts, in an array of larger one, e.g. @c ARRAY_INT, does | |
146 | not work on all architectures!). | |
7c913512 | 147 | |
23324ae1 FM |
148 | @library{wxbase} |
149 | @category{FIXME} | |
7c913512 | 150 | |
b1db61e1 | 151 | @see @ref overview_container, wxList<T>, wxVector<T> |
23324ae1 | 152 | */ |
7c913512 | 153 | class wxArray<T> |
23324ae1 FM |
154 | { |
155 | public: | |
156 | //@{ | |
157 | /** | |
4cc4bfaf | 158 | Appends the given number of @a copies of the @a item to the array |
23324ae1 | 159 | consisting of the elements of type @e T. |
23324ae1 | 160 | The first version is used with wxArray. The second is used with wxSortedArray, |
4cc4bfaf | 161 | returning the index where @a item is stored. The third and the |
23324ae1 FM |
162 | fourth ones are used with wxObjArray. There is an important difference between |
163 | them: if you give a pointer to the array, it will take ownership of it, i.e. | |
164 | will delete it when the item is deleted from the array. If you give a reference | |
165 | to the array, however, the array will make a copy of the item and will not take | |
166 | ownership of the original item. Once again, it only makes sense for wxObjArrays | |
167 | because the other array types never take ownership of their elements. Also note | |
168 | that you cannot append more than one pointer as reusing it would lead to | |
169 | deleting it twice (or more) and hence to a crash. | |
e54c96f1 | 170 | You may also use WX_APPEND_ARRAY() macro to append all |
23324ae1 | 171 | elements of one array to another one but it is more efficient to use |
4cc4bfaf | 172 | @a copies parameter and modify the elements in place later if you plan to |
23324ae1 FM |
173 | append a lot of items. |
174 | */ | |
175 | void Add(T item, size_t copies = 1); | |
7c913512 | 176 | size_t Add(T item); |
4cc4bfaf FM |
177 | void Add(T* item); |
178 | void Add(T& item, size_t copies = 1); | |
23324ae1 FM |
179 | //@} |
180 | ||
181 | /** | |
4cc4bfaf | 182 | Inserts the given @a item into the array in the specified @e index |
23324ae1 | 183 | position. |
23324ae1 FM |
184 | Be aware that you will set out the order of the array if you give a wrong |
185 | position. | |
7c913512 | 186 | This function is useful in conjunction with |
23324ae1 FM |
187 | wxArray::IndexForInsert for a common operation |
188 | of "insert only if not found". | |
189 | */ | |
190 | void AddAt(T item, size_t index); | |
191 | ||
192 | /** | |
193 | wxArray::Add | |
3c4f71cc | 194 | |
23324ae1 | 195 | wxArray::AddAt |
3c4f71cc | 196 | |
23324ae1 | 197 | wxArray::Insert |
3c4f71cc | 198 | |
23324ae1 | 199 | wxArray::SetCount |
3c4f71cc | 200 | |
e54c96f1 | 201 | WX_APPEND_ARRAY() |
3c4f71cc | 202 | |
e54c96f1 | 203 | WX_PREPEND_ARRAY() |
23324ae1 FM |
204 | */ |
205 | ||
206 | ||
207 | /** | |
208 | Preallocates memory for a given number of array elements. It is worth calling | |
209 | when the number of items which are going to be added to the array is known in | |
210 | advance because it will save unneeded memory reallocation. If the array already | |
211 | has enough memory for the given number of items, nothing happens. In any case, | |
212 | the existing contents of the array is not modified. | |
213 | */ | |
214 | void Alloc(size_t count); | |
215 | ||
216 | /** | |
217 | This function does the same as wxArray::Empty and additionally | |
218 | frees the memory allocated to the array. | |
219 | */ | |
220 | void Clear(); | |
221 | ||
222 | /** | |
223 | Array classes are 100% C++ objects and as such they have the appropriate copy | |
224 | constructors and assignment operators. Copying wxArray just copies the elements | |
225 | but copying wxObjArray copies the arrays items. However, for memory-efficiency | |
226 | sake, neither of these classes has virtual destructor. It is not very important | |
227 | for wxArray which has trivial destructor anyhow, but it does mean that you | |
228 | should avoid deleting wxObjArray through a wxBaseArray pointer (as you would | |
229 | never use wxBaseArray anyhow it shouldn't be a problem) and that you should not | |
230 | derive your own classes from the array classes. | |
23324ae1 | 231 | @ref wxArray::ctordef "wxArray default constructor" |
3c4f71cc | 232 | |
23324ae1 | 233 | @ref wxArray::ctorcopy "wxArray copy constructors and assignment operators" |
3c4f71cc | 234 | |
23324ae1 FM |
235 | @ref wxArray::dtor ~wxArray |
236 | */ | |
237 | ||
238 | ||
239 | //@{ | |
240 | /** | |
241 | (T first, T second)@e compareFunction) | |
23324ae1 FM |
242 | There is no default constructor for wxSortedArray classes - you must initialize |
243 | it | |
244 | with a function to use for item comparison. It is a function which is passed | |
245 | two arguments of type @e T where @e T is the array element type and which | |
246 | should return a negative, zero or positive value according to whether the first | |
247 | element passed to it is less than, equal to or greater than the second one. | |
248 | */ | |
7c913512 FM |
249 | wxArray(); |
250 | wxObjArray(); | |
251 | wxSortedArray(); | |
23324ae1 FM |
252 | //@} |
253 | ||
254 | /** | |
255 | Removes the element from the array, but, unlike, | |
256 | wxArray::Remove doesn't delete it. The function returns the | |
257 | pointer to the removed element. | |
258 | */ | |
4cc4bfaf | 259 | T* Detach(size_t index); |
23324ae1 FM |
260 | |
261 | /** | |
262 | Empties the array. For wxObjArray classes, this destroys all of the array | |
263 | elements. For wxArray and wxSortedArray this does nothing except marking the | |
264 | array of being empty - this function does not free the allocated memory, use | |
265 | wxArray::Clear for this. | |
266 | */ | |
267 | void Empty(); | |
268 | ||
269 | /** | |
270 | Return the number of items in the array. | |
271 | */ | |
328f5751 | 272 | size_t GetCount() const; |
23324ae1 FM |
273 | |
274 | //@{ | |
275 | /** | |
276 | The first version of the function is for wxArray and wxObjArray, the second is | |
277 | for wxSortedArray only. | |
23324ae1 | 278 | Searches the element in the array, starting from either beginning or the end |
4cc4bfaf | 279 | depending on the value of @a searchFromEnd parameter. @c wxNOT_FOUND is |
23324ae1 FM |
280 | returned if the element is not found, otherwise the index of the element is |
281 | returned. | |
23324ae1 FM |
282 | Linear search is used for the wxArray and wxObjArray classes but binary search |
283 | in the sorted array is used for wxSortedArray (this is why searchFromEnd | |
284 | parameter doesn't make sense for it). | |
1f1d2182 | 285 | @note even for wxObjArray classes, the operator==() of the elements in the |
23324ae1 FM |
286 | array is @b not used by this function. It searches exactly the given |
287 | element in the array and so will only succeed if this element had been | |
288 | previously added to the array, but fail even if another, identical, element is | |
289 | in the array. | |
290 | */ | |
328f5751 FM |
291 | int Index(T& item, bool searchFromEnd = false) const; |
292 | const int Index(T& item) const; | |
23324ae1 FM |
293 | //@} |
294 | ||
295 | /** | |
4cc4bfaf | 296 | Search for a place to insert @a item into the sorted array (binary search). |
23324ae1 FM |
297 | The index returned is just before the first existing item that is greater or |
298 | equal | |
299 | (according to the compare function) to the given @e item. | |
4cc4bfaf | 300 | You have to do extra work to know if the @a item already exists in array. |
7c913512 | 301 | This function is useful in conjunction with |
23324ae1 FM |
302 | wxArray::AddAt for a common operation |
303 | of "insert only if not found". | |
304 | */ | |
328f5751 | 305 | size_t IndexForInsert(T item) const; |
23324ae1 FM |
306 | |
307 | //@{ | |
308 | /** | |
4cc4bfaf FM |
309 | Insert the given number of @a copies of the @a item into the array before |
310 | the existing item @a n - thus, @e Insert(something, 0u) will insert an | |
23324ae1 | 311 | item in such way that it will become the first array element. |
23324ae1 FM |
312 | wxSortedArray doesn't have this function because inserting in wrong place |
313 | would break its sorted condition. | |
23324ae1 FM |
314 | Please see wxArray::Add for explanation of the differences |
315 | between the overloaded versions of this function. | |
316 | */ | |
317 | void Insert(T item, size_t n, size_t copies = 1); | |
4cc4bfaf FM |
318 | void Insert(T* item, size_t n); |
319 | void Insert(T& item, size_t n, size_t copies = 1); | |
23324ae1 FM |
320 | //@} |
321 | ||
322 | /** | |
323 | Returns @true if the array is empty, @false otherwise. | |
324 | */ | |
328f5751 | 325 | bool IsEmpty() const; |
23324ae1 FM |
326 | |
327 | /** | |
4cc4bfaf | 328 | Returns the item at the given position in the array. If @a index is out of |
23324ae1 FM |
329 | bounds, an assert failure is raised in the debug builds but nothing special is |
330 | done in the release build. | |
23324ae1 FM |
331 | The returned value is of type "reference to the array element type" for all of |
332 | the array classes. | |
333 | */ | |
328f5751 | 334 | T Item(size_t index) const; |
23324ae1 FM |
335 | |
336 | /** | |
337 | Returns the last element in the array, i.e. is the same as Item(GetCount() - 1). | |
338 | An assert failure is raised in the debug mode if the array is empty. | |
23324ae1 FM |
339 | The returned value is of type "reference to the array element type" for all of |
340 | the array classes. | |
341 | */ | |
328f5751 | 342 | T Last() const; |
23324ae1 FM |
343 | |
344 | /** | |
345 | To use an array you must first define the array class. This is done with the | |
346 | help of the macros in this section. The class of array elements must be (at | |
347 | least) forward declared for WX_DEFINE_ARRAY, WX_DEFINE_SORTED_ARRAY and | |
348 | WX_DECLARE_OBJARRAY macros and must be fully declared before you use | |
349 | WX_DEFINE_OBJARRAY macro. | |
e54c96f1 | 350 | WX_DEFINE_ARRAY() |
3c4f71cc | 351 | |
e54c96f1 | 352 | WX_DEFINE_EXPORTED_ARRAY() |
3c4f71cc | 353 | |
e54c96f1 | 354 | WX_DEFINE_USER_EXPORTED_ARRAY() |
3c4f71cc | 355 | |
e54c96f1 | 356 | WX_DEFINE_SORTED_ARRAY() |
3c4f71cc | 357 | |
e54c96f1 | 358 | WX_DEFINE_SORTED_EXPORTED_ARRAY() |
3c4f71cc | 359 | |
e54c96f1 | 360 | WX_DEFINE_SORTED_USER_EXPORTED_ARRAY() |
3c4f71cc | 361 | |
e54c96f1 | 362 | WX_DECLARE_EXPORTED_OBJARRAY() |
3c4f71cc | 363 | |
e54c96f1 | 364 | WX_DECLARE_USER_EXPORTED_OBJARRAY() |
3c4f71cc | 365 | |
e54c96f1 | 366 | WX_DEFINE_OBJARRAY() |
3c4f71cc | 367 | |
e54c96f1 | 368 | WX_DEFINE_EXPORTED_OBJARRAY() |
3c4f71cc | 369 | |
e54c96f1 | 370 | WX_DEFINE_USER_EXPORTED_OBJARRAY() |
23324ae1 FM |
371 | To slightly complicate the matters even further, the operator - defined by |
372 | default for the array iterators by these macros only makes sense if the array | |
373 | element type is not a pointer itself and, although it still works, this | |
374 | provokes warnings from some compilers and to avoid them you should use the | |
375 | @c _PTR versions of the macros above. For example, to define an array of | |
376 | pointers to @c double you should use: | |
3c4f71cc | 377 | |
23324ae1 FM |
378 | Note that the above macros are generally only useful for |
379 | wxObject types. There are separate macros for declaring an array of a simple | |
380 | type, | |
381 | such as an int. | |
23324ae1 | 382 | The following simple types are supported: |
3c4f71cc | 383 | |
23324ae1 | 384 | int |
3c4f71cc | 385 | |
23324ae1 | 386 | long |
3c4f71cc | 387 | |
23324ae1 | 388 | size_t |
3c4f71cc | 389 | |
23324ae1 | 390 | double |
23324ae1 FM |
391 | To create an array of a simple type, simply append the type you want in CAPS to |
392 | the array definition. | |
23324ae1 | 393 | For example, for an integer array, you'd use one of the following variants: |
e54c96f1 | 394 | WX_DEFINE_ARRAY_INT() |
3c4f71cc | 395 | |
e54c96f1 | 396 | WX_DEFINE_EXPORTED_ARRAY_INT() |
3c4f71cc | 397 | |
e54c96f1 | 398 | WX_DEFINE_USER_EXPORTED_ARRAY_INT() |
3c4f71cc | 399 | |
e54c96f1 | 400 | WX_DEFINE_SORTED_ARRAY_INT() |
3c4f71cc | 401 | |
e54c96f1 | 402 | WX_DEFINE_SORTED_EXPORTED_ARRAY_INT() |
3c4f71cc | 403 | |
e54c96f1 | 404 | WX_DEFINE_SORTED_USER_EXPORTED_ARRAY_INT() |
23324ae1 FM |
405 | */ |
406 | ||
407 | ||
408 | /** | |
409 | Automatic array memory management is quite trivial: the array starts by | |
410 | preallocating some minimal amount of memory (defined by | |
411 | WX_ARRAY_DEFAULT_INITIAL_SIZE) and when further new items exhaust already | |
412 | allocated memory it reallocates it adding 50% of the currently allocated | |
413 | amount, but no more than some maximal number which is defined by | |
414 | ARRAY_MAXSIZE_INCREMENT constant. Of course, this may lead to some memory | |
415 | being wasted (ARRAY_MAXSIZE_INCREMENT in the worst case, i.e. 4Kb in the | |
416 | current implementation), so the wxArray::Shrink function is | |
417 | provided to deallocate the extra memory. The wxArray::Alloc | |
418 | function can also be quite useful if you know in advance how many items you are | |
419 | going to put in the array and will prevent the array code from reallocating the | |
420 | memory more times than needed. | |
23324ae1 | 421 | wxArray::Alloc |
3c4f71cc | 422 | |
23324ae1 FM |
423 | wxArray::Shrink |
424 | */ | |
425 | ||
426 | ||
427 | /** | |
428 | Functions in this section return the total number of array elements and allow to | |
429 | retrieve them - possibly using just the C array indexing [] operator which | |
430 | does exactly the same as wxArray::Item method. | |
23324ae1 | 431 | wxArray::GetCount |
3c4f71cc | 432 | |
23324ae1 | 433 | wxArray::IsEmpty |
3c4f71cc | 434 | |
23324ae1 | 435 | wxArray::Item |
3c4f71cc | 436 | |
23324ae1 FM |
437 | wxArray::Last |
438 | */ | |
439 | ||
440 | ||
441 | /** | |
442 | Removes an element from the array by value: the first item of the | |
4cc4bfaf | 443 | array equal to @a item is removed, an assert failure will result from an |
23324ae1 | 444 | attempt to remove an item which doesn't exist in the array. |
23324ae1 | 445 | When an element is removed from wxObjArray it is deleted by the array - use |
e54c96f1 | 446 | Detach() if you don't want this to happen. On the |
23324ae1 FM |
447 | other hand, when an object is removed from a wxArray nothing happens - you |
448 | should delete it manually if required: | |
3c4f71cc | 449 | |
e54c96f1 | 450 | See also WX_CLEAR_ARRAY() macro which deletes all |
23324ae1 FM |
451 | elements of a wxArray (supposed to contain pointers). |
452 | */ | |
7c913512 | 453 | Remove(T item); |
23324ae1 FM |
454 | |
455 | /** | |
4cc4bfaf | 456 | Removes @a count elements starting at @a index from the array. When an |
23324ae1 | 457 | element is removed from wxObjArray it is deleted by the array - use |
e54c96f1 | 458 | Detach() if you don't want this to happen. On |
23324ae1 FM |
459 | the other hand, when an object is removed from a wxArray nothing happens - |
460 | you should delete it manually if required: | |
3c4f71cc | 461 | |
e54c96f1 | 462 | See also WX_CLEAR_ARRAY() macro which deletes all |
23324ae1 FM |
463 | elements of a wxArray (supposed to contain pointers). |
464 | */ | |
7c913512 | 465 | RemoveAt(size_t index, size_t count = 1); |
23324ae1 FM |
466 | |
467 | /** | |
e54c96f1 | 468 | WX_CLEAR_ARRAY() |
3c4f71cc | 469 | |
23324ae1 | 470 | wxArray::Empty |
3c4f71cc | 471 | |
23324ae1 | 472 | wxArray::Clear |
3c4f71cc | 473 | |
23324ae1 | 474 | wxArray::RemoveAt |
3c4f71cc | 475 | |
23324ae1 FM |
476 | wxArray::Remove |
477 | */ | |
478 | ||
479 | ||
480 | /** | |
481 | wxArray::Index | |
3c4f71cc | 482 | |
23324ae1 | 483 | wxArray::IndexForInsert |
3c4f71cc | 484 | |
23324ae1 FM |
485 | wxArray::Sort |
486 | */ | |
487 | ||
488 | ||
489 | /** | |
490 | ) | |
23324ae1 | 491 | This function ensures that the number of array elements is at least |
4cc4bfaf | 492 | @e count. If the array has already @a count or more items, nothing is |
23324ae1 FM |
493 | done. Otherwise, @c count - GetCount() elements are added and initialized to |
494 | the value @e defval. | |
3c4f71cc | 495 | |
4cc4bfaf | 496 | @see wxArray::GetCount |
23324ae1 FM |
497 | */ |
498 | void SetCount(size_t count); | |
499 | ||
500 | /** | |
501 | Frees all memory unused by the array. If the program knows that no new items | |
502 | will be added to the array it may call Shrink() to reduce its memory usage. | |
503 | However, if a new item is added to the array, some extra memory will be | |
504 | allocated again. | |
505 | */ | |
506 | void Shrink(); | |
507 | ||
508 | /** | |
509 | The notation CMPFUNCT should be read as if we had the following declaration: | |
3c4f71cc | 510 | |
23324ae1 FM |
511 | where @e T is the type of the array elements. I.e. it is a function returning |
512 | @e int which is passed two arguments of type @e T *. | |
23324ae1 FM |
513 | Sorts the array using the specified compare function: this function should |
514 | return a negative, zero or positive value according to whether the first element | |
515 | passed to it is less than, equal to or greater than the second one. | |
23324ae1 FM |
516 | wxSortedArray doesn't have this function because it is always sorted. |
517 | */ | |
518 | void Sort(CMPFUNC<T> compareFunction); | |
519 | ||
23324ae1 FM |
520 | //@{ |
521 | /** | |
522 | The copy constructors and assignment operators perform a shallow array copy | |
523 | (i.e. they don't copy the objects pointed to even if the source array contains | |
524 | the items of pointer type) for wxArray and wxSortedArray and a deep copy (i.e. | |
525 | the array element are copied too) for wxObjArray. | |
526 | */ | |
7c913512 FM |
527 | wxArray(const wxArray& array); |
528 | wxSortedArray(const wxSortedArray& array); | |
529 | wxObjArray(const wxObjArray& array); | |
530 | wxArray operator=(const wxArray& array); | |
531 | wxSortedArray operator=(const wxSortedArray& array); | |
532 | wxObjArray operator=(const wxObjArray& array); | |
23324ae1 FM |
533 | //@} |
534 | ||
535 | //@{ | |
536 | /** | |
537 | The wxObjArray destructor deletes all the items owned by the array. This is not | |
538 | done by wxArray and wxSortedArray versions - you may use | |
e54c96f1 | 539 | WX_CLEAR_ARRAY() macro for this. |
23324ae1 | 540 | */ |
7c913512 FM |
541 | ~wxArray(); |
542 | ~wxSortedArray(); | |
543 | ~wxObjArray(); | |
23324ae1 FM |
544 | //@} |
545 | }; | |
e54c96f1 | 546 | |
6b4a130c FM |
547 | |
548 | /** | |
549 | This macro may be used to append all elements of the @a other array to the | |
550 | @e array. The two arrays must be of the same type. | |
551 | */ | |
552 | #define WX_APPEND_ARRAY(wxArray& array, wxArray& other) /* implementation is private */ | |
553 | ||
554 | /** | |
555 | This macro may be used to delete all elements of the array before emptying it. | |
556 | It can not be used with wxObjArrays - but they will delete their elements anyhow | |
557 | when you call Empty(). | |
558 | */ | |
559 | #define WX_CLEAR_ARRAY(wxArray& array) /* implementation is private */ | |
560 | ||
561 | //@{ | |
562 | /** | |
563 | This macro declares a new object array class named @a name and containing | |
564 | the elements of type @e T. The second form is used when compiling wxWidgets as | |
565 | a DLL under Windows and array needs to be visible outside the DLL. The third is | |
566 | needed for exporting an array from a user DLL. | |
567 | Example: | |
568 | ||
569 | You must use WX_DEFINE_OBJARRAY() macro to define | |
570 | the array class - otherwise you would get link errors. | |
571 | */ | |
572 | #define WX_DECLARE_OBJARRAY(T, name) /* implementation is private */ | |
573 | #define WX_DECLARE_EXPORTED_OBJARRAY(T, name) /* implementation is private */ | |
574 | #define WX_DECLARE_USER_EXPORTED_OBJARRAY(T, name) /* implementation is private */ | |
575 | //@} | |
576 | ||
577 | //@{ | |
578 | /** | |
579 | This macro defines a new array class named @a name and containing the | |
580 | elements of type @e T. The second form is used when compiling wxWidgets as | |
581 | a DLL under Windows and array needs to be visible outside the DLL. The third is | |
582 | needed for exporting an array from a user DLL. | |
583 | Example: | |
584 | ||
585 | Note that wxWidgets predefines the following standard array classes: @b | |
586 | wxArrayInt, | |
587 | @b wxArrayLong, @b wxArrayShort, @b wxArrayDouble, @b wxArrayPtrVoid. | |
588 | */ | |
589 | #define WX_DEFINE_ARRAY(T, name) /* implementation is private */ | |
590 | #define WX_DEFINE_EXPORTED_ARRAY(T, name) /* implementation is private */ | |
591 | #define WX_DEFINE_USER_EXPORTED_ARRAY(T, name, exportspec) /* implementation is private */ | |
592 | //@} | |
593 | ||
594 | //@{ | |
595 | /** | |
596 | This macro defines the methods of the array class @a name not defined by the | |
597 | WX_DECLARE_OBJARRAY() macro. You must include the | |
598 | file wx/arrimpl.cpp before using this macro and you must have the full | |
599 | declaration of the class of array elements in scope! If you forget to do the | |
600 | first, the error will be caught by the compiler, but, unfortunately, many | |
601 | compilers will not give any warnings if you forget to do the second - but the | |
602 | objects of the class will not be copied correctly and their real destructor will | |
603 | not be called. The latter two forms are merely aliases of the first to satisfy | |
604 | some people's sense of symmetry when using the exported declarations. | |
605 | Example of usage: | |
606 | */ | |
607 | #define WX_DEFINE_OBJARRAY(name) /* implementation is private */ | |
608 | #define WX_DEFINE_EXPORTED_OBJARRAY(name) /* implementation is private */ | |
609 | #define WX_DEFINE_USER_EXPORTED_OBJARRAY(name) /* implementation is private */ | |
610 | //@} | |
611 | ||
612 | //@{ | |
613 | /** | |
614 | This macro defines a new sorted array class named @a name and containing | |
615 | the elements of type @e T. The second form is used when compiling wxWidgets as | |
616 | a DLL under Windows and array needs to be visible outside the DLL. The third is | |
617 | needed for exporting an array from a user DLL. | |
618 | Example: | |
619 | ||
620 | You will have to initialize the objects of this class by passing a comparison | |
621 | function to the array object constructor like this: | |
622 | */ | |
623 | #define WX_DEFINE_SORTED_ARRAY(T, name) /* implementation is private */ | |
624 | #define WX_DEFINE_SORTED_EXPORTED_ARRAY(T, name) /* implementation is private */ | |
625 | #define WX_DEFINE_SORTED_USER_EXPORTED_ARRAY(T, name) /* implementation is private */ | |
626 | //@} | |
627 | ||
628 | /** | |
629 | This macro may be used to prepend all elements of the @a other array to the | |
630 | @e array. The two arrays must be of the same type. | |
631 | */ | |
632 | #define WX_PREPEND_ARRAY(wxArray& array, wxArray& other) /* implementation is private */ |