ucx: comparison docs/Writerside/topics/iterator.h.md

-:9a72258446cd
+:563033aa998c
 This allows iteration over arrays, lists, maps, trees, etc. in a unified way.
 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.
 ```C
 #include <cx/iterator.h>
 The macro takes three arguments:
 1. the pointer-type of a pointer to an element,
 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.
 >
 > You should read the documentation of the function creating the iterator to learn
 > what exactly the iterator is iterating over.
 If you are implementing your own iterator, it is up to you to implement this behavior.
 ## 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
 which can be obtained with the `cxIteratorRef()` macro on the calling site.
 Iterators may be wrapped in which case the original implementation can be stored in `current_impl` and
 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,
+A specialized, simple, and fast iterator over an array of a certain type
-that does not support mutation, can be implemented as follows:
+that does not support mutation can be implemented as follows:
 ```C
 #include <cx/iterator.h>
 typedef struct my_foo_s {
 // ... your data ...
 }
 ```
 > 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">
 <a href="https://ucx.sourceforge.io/api/iterator_8h.html">iterator.h</a>
 </category>

Mercurial > hg > ucx / file comparison

comparison: docs/Writerside/topics/iterator.h.md

docs/Writerside/topics/iterator.h.md