comparison: docs/src/features.md
docs/src/features.md
- changeset 730
- 9fecb2769d32
- parent 729
- 600d72644919
- child 731
- 9c097dabba2c
equal
deleted
inserted
replaced
| 729:600d72644919 | 730:9fecb2769d32 |
|---|---|
| 183 *Header file:* [iterator.h](api/iterator_8h.html) | 183 *Header file:* [iterator.h](api/iterator_8h.html) |
| 184 | 184 |
| 185 ## Collection | 185 ## Collection |
| 186 | 186 |
| 187 *Header file:* [collection.h](api/collection_8h.html) | 187 *Header file:* [collection.h](api/collection_8h.html) |
| 188 | |
| 189 Collections in UCX 3 have several common features. | |
| 190 If you want to implement an own collection data type that uses the same features, you can use the | |
| 191 `CX_COLLECTION_MEMBERS` macro at the beginning of your struct to roll out all members a usual UCX collection has. | |
| 192 ```c | |
| 193 struct my_fancy_collection_s { | |
| 194 CX_COLLECTION_MEMBERS | |
| 195 struct my_collection_data_s *data; | |
| 196 }; | |
| 197 ``` | |
| 198 Based on this structure, this header provides some convenience macros for invoking the destructor functions | |
| 199 that are part of the basic collection members. | |
| 200 The idea of having destructor functions within a collection is that you can destroy the collection _and_ the | |
| 201 contents with one single function call. | |
| 202 When you are implementing a collection, you are responsible for invoking the destructors at the right places, e.g. | |
| 203 when removing (and deleting) elements in the collection, clearing the collection, or - the most prominent case - | |
| 204 destroying the collection. | |
| 205 | |
| 206 You can always look at the UCX list and map implementations if you need some inspiration. | |
| 188 | 207 |
| 189 ## List | 208 ## List |
| 190 | 209 |
| 191 *Header file:* [list.h](api/list_8h.html) | 210 *Header file:* [list.h](api/list_8h.html) |
| 192 | 211 |
