PengZheng commented on PR #470:
URL: https://github.com/apache/celix/pull/470#issuecomment-1817754005
> Ah I see, no this was not intentionally and I think it is better to keep
the max iterator index on map size. Refactor the index increment for this.
From the following documentation, I get the original intention of `index`:
```C
typedef struct celix_string_hash_map_iterator {
size_t index; /**< The index of the iterator. Starts at 0, ends at
map size (so beyond the last element). When an
entry is removed, the index value is not changed. */
```
And yes, `celix_stringHashMapIterator_next allows iter->index >
map->genericMap.size` is intentionally allowed.
I noticed the newly added test `TEST_F(HashMapTestSuite,
IterateWithRemoveAtIndex4Test)` seems weird:
```C
celix_autoptr(celix_string_hash_map_t) sMap = createStringHashMap(6);
auto iter1 = celix_stringHashMap_begin(sMap);
while (!celix_stringHashMapIterator_isEnd(&iter1)) {
if (iter1.index == 4) {
// note only removing entries where the iter key is even
celix_stringHashMapIterator_remove(&iter1);
} else {
celix_stringHashMapIterator_next(&iter1);
}
}
EXPECT_EQ(4, celix_stringHashMap_size(sMap));
```
4 rather than 5 entries remain.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
