Neat. Here's what I'd keep: just an epoch saying when the last valid element of the vector is. The iterator just needs a ptr to the vector and the vector's data. It's a constant time lookup, with somewhat heavier iterators. I guess this is something like MSFT's old debug iterators?
Interesting that they chose not to implement any method to detect whether a given iterator has been invalidated, even though the implementation would be easy. Seems it would be a useful extension, especially since any serious usage of this vector type would already be relying on functionality not provided by the standard vector class.
What is the core use case for this structure? Because it seems like a very heavy price to pay just to keep value stable, as opposed to make a copy of that value when you need it.
> The same iterator object can't be used concurrently in different threads, even for nominally const operations such as dereferencing (internally, thread-unsafe epoch traversal is triggered)
If I understand correctly:
thread safety random access stable iterators
------------- ------------- ----------------
std::list thread-compatible no yes
std::vector thread-compatible yes no
std::deque thread-compatible yes no
semistable::vector thread-unsafe yes yes
I think there are more times when I wanted concurrent reads and (random access OR stable iterators), than when I wanted both random access AND stable iterators but not concurrent reads. I wonder what's the intended application?
The utility of such container seems for me to be questionable. It's likely an error to modify vector while iterators to its elements exist. I see no legit reason to modify a vector with preservation of iterators.
6 comments
[ 3.4 ms ] story [ 14.5 ms ] threadIf I understand correctly:
I think there are more times when I wanted concurrent reads and (random access OR stable iterators), than when I wanted both random access AND stable iterators but not concurrent reads. I wonder what's the intended application?