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