A proof of concept of a semistable C++ vector container
30 points by joaquintides
by Panzerschrek
0 subcomment
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.
by shin_lao
2 subcomments
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.
by unnah
0 subcomment
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.
by thechao
0 subcomment
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?
by omoikane
0 subcomment
> 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?
Hacker News