Mercurial > hg > ucx / changeset

--- a/docs/Writerside/topics/iterator.h.md	Tue Dec 16 15:57:51 2025 +0100
+++ b/docs/Writerside/topics/iterator.h.md	Tue Dec 16 16:01:37 2025 +0100
@@ -8,7 +8,7 @@
 
 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.
+and place the `CX_ITERATOR_BASE` macro as the first member of that structure.
 
 ```C
 #include <cx/iterator.h>
@@ -36,7 +36,7 @@
 The `cxIterator()` function creates an iterator over the elements of `array` where
 each element is `elem_size` bytes large and the array contains a total of `elem_count` elements.
 
-The `cxIteratorPtr()` on the other hand assumes `sizeof(void*)` as the `elem_size` and automatically dereferences the pointers to the array elements.
+The `cxIteratorPtr()`, on the other hand, assumes `sizeof(void*)` as the `elem_size` and automatically dereferences the pointers to the array elements.
 That means, values returned by the iterator created with `cxIteratorPtr()` are the pointers stored in the array,
 while iterators created `cxIterator()` yield the pointers to the elements in the array. 
 
@@ -88,16 +88,15 @@
 Usually an iterator is not mutating the collection it is iterating over.
 But sometimes it is desirable to remove an element from the collection while iterating over it.
 
-For this purpose, most collections allow to use `cxIteratorFlagRemoval()`, which instructs the iterator to remove
+For this purpose, most collections allow using `cxIteratorFlagRemoval()`, which instructs the iterator to remove
 the current element from the collection on the next call to `cxIteratorNext()`.
 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 using macros.
+To eliminate the need of memory management for iterators, the structures are usually passed by value.
+However, sometimes it is necessary to pass an iterator to another function.
 
-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.
 
@@ -111,7 +110,7 @@
 cxTreeInsertIter(tree, cxIteratorRef(iter), cxListSize(list));
 ```
 
-> This is the reason, why `CX_ITERATOR_BASE` must be the first member of any iterator structure.
+> This is the reason why `CX_ITERATOR_BASE` must be the first member of any iterator structure.
 > Otherwise, the address taken by `cxIteratorRef()` would not equal the address of the iterator.
 {style="note"}
 
@@ -194,7 +193,7 @@
 }
 ```
 
-> Note, that the behavior of `current` is undefined when `valid` returns `false`.
+> 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`.
 {style="note"}