--- a/docs/Writerside/topics/iterator.h.md Sat Oct 11 15:42:48 2025 +0200 +++ b/docs/Writerside/topics/iterator.h.md Sun Oct 12 20:21:56 2025 +0200 @@ -6,7 +6,7 @@ Creating an iterator is as simple as creating a `CxIterator` struct and setting the fields in a meaningful way. The UCX collections provide various functions to create such iterators. -If the predefined fields are insufficient (or introduce too much bloat) for your use case, +If the predefined fields are not enough (or introduce too much bloat) for your use case, you can alternatively create your own iterator structure and place the `CX_ITERATOR_BASE` macro as first member of that structure. @@ -79,7 +79,7 @@ 2. the name of the variable you want to use for accessing the element, 3. and the iterator. -> An iterator does not necessarily need to iterate over the elements of a collections. +> An iterator does not necessarily need to iterate over the concrete elements of a collection. > Map iterators, for example, can iterator over the key/value pairs, > but they can also iterate over just the values or just the keys. > @@ -100,7 +100,7 @@ ## Passing Iterators to Functions To eliminate the need of memory management for iterators, the structures are usually used by value. -This does not come with additional costs, because iteration is implemented entirely by macros. +This does not come with additional costs because iteration is implemented entirely by using macros. However, sometimes it is necessary to pass an iterator to another function. To make that possible in a generalized way, such functions should accept a `CxIteratorBase*` pointer @@ -145,8 +145,8 @@ called by a wrapper implementation pointed to by `current`. This can be useful when you want to support the `store_pointer` field of the [](collection.h.md) API. -A specialized, simple, and fast iterator over an array of a certain type, -that does not support mutation, can be implemented as follows: +A specialized, simple, and fast iterator over an array of a certain type +that does not support mutation can be implemented as follows: ```C #include <cx/iterator.h> @@ -196,11 +196,11 @@ > Note, that the behavior of `current` is undefined when `valid` returns `false`. > That means, on the one hand, `current` does not need to check for validity of the iterator, -> but on the other hand it is forbidden to invoke `current` when `valid` would return `false`. +> but on the other hand, it is forbidden to invoke `current` when `valid` would return `false`. {style="note"} > If performance matters in your application, it is recommended that you indeed create specialized iterators -> for your collections. The default UCX implementations trade some of the performance for generality. +> for your collections. The default UCX implementations trade some performance for generality. <seealso> <category ref="apidoc">