Simon, its QUOTE FROM STANDARD - "in case when no reallocation happen"

ср, 10 дек. 2025 г. в 11:11, Simon Schröder via Std-Proposals <
std-proposals_at_[hidden]>:

> The major problem I see with this proposal is the “if the vector storage
> is not reallocated”. In the general case I can’t even know it. The only
> special case I think to know is after a reserve(). From the top of my head
> I’m not even sure if the reserve is guaranteed by the standard to allocate
> the memory.
>
> Even then the strongest argument against this proposal is maintainability:
> at some point someone might just push another element and not update the
> size in the reserve. This will suddenly bring you into UB again. Adding a
> single push_back() should not change valid code into UB (it doesn’t right
> now because it would have been UB in the first place).
>
> I believe the wording in the standard to be much easier (and less error
> prone) the way it is right now. Adding your proposals might add a “bug” in
> the standard.
>
> On Dec 8, 2025, at 3:45 PM, Nikl Kelbon via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
> 
> The standard needs to better clarify the section on vector iterator
> invalidation.
>
> *Why i think its important:*
>
> Some implementations added checks like: "oh, we must store all .end()
> iterators into global map under mutex and mark them invalid on each
> push_back, it will be SO useful for our developers!"
> So, minimal example where it breaks completely:
>
> std::vector<int> v;
> v.reserve(10);
>
> v.push_back(1);
>
> auto b = v.begin();
> auto e = v.end();
> v.push_back(1);
> ++b;
> REQUIRE(b == e); // assertion failure:
> // _STL_VERIFY(this->_Getcont() == _Right._Getcont(), "vector iterators incompatible");
>
>
> Its common pattern when using vector to reserve memory and push values,
> there are no "better way to do it", thats why it must be valid
>
>
> *Now about standard:*
>
> here's a quote from the standard regarding append_range and, apparently,
> push_back (https://eel.is/c++draft/vector#modifiers-2):
>
>
> If no reallocation happens, then references, pointers, and iterators
> before the insertion point remain valid but those at or after the insertion
> point, including the past-the-end iterator, are invalidated
>
>
> It explicitly states that despite there are no relocation happen, the
> past-the-end iterator is invalidated, although there's no reason for a
> vector to be so.
> Yes, a* past-the-end iterator will no longer be past-the-end, but that
> doesn't make it invalid*. In any implementation, even a foolish one, it's
> hard to imagine how, without relocation, this iterator could become
> anything other than just an iterator to the last element of the vector.
>
> I think in this case *standard should separate invalidation and what
> happens here - its not invalidation rly.*
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>