wt., 9 gru 2025 o 10:32 Nikl Kelbon via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> you wrote bug while trying to avoid useless and incorrect standard wording, thats why it must be changed
>

No, this is not a bug, MSVC behavior is perfect and needed by every
serious programmer, other compilers should have similar features.
Nobody wants to have a vector that self updates like that in their
codebase and is perfect if the compiler detected it early.
Bugs like this can easily stay hidden as used range is in available
capacity but when you run the same code in production limits
can be easy to reach and we get crash in best case and in worst
security exploit.

> вт, 9 дек. 2025 г. в 14:29, Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>:
>>
>> Isn't it enough, if the for loop checks for the last element instead of one beyond?
>>
>>
>>
>> This would work with all containers with bidirectional iterators. For forward_list there is not even a push_back() function.
>>
>>
>>
>>
>>
>> #include <vector>
>>
>> struct mytype {
>> std::vector<int> vec;
>>
>> // in real code it is complex iterator
>> // where vector iterator only part of it
>> using iterator = std::vector<int>::iterator;
>>
>> void append(iterator b, iterator e) {
>>
>>
>>
>> --e; // INSERT
>>
>>
>> for (; b != e; ++b) { // ASSERTION FAILURE, COMPARING b and e after push_back
>> // again, in real code it complex operation with inserting in my container
>> vec.push_back(*b);
>> }
>>
>>
>>
>> vec.push_back(*b); // INSERT
>>
>>
>> }
>>
>> iterator begin() {
>> return vec.begin();
>> }
>> iterator end() {
>> return vec.end();
>> }
>> };
>>
>> int main() {
>> mytype x;
>> x.vec = {1, 2, 3, 4};
>> x.vec.reserve(100);
>> x.append(x.begin(), x.end());
>> }
>>
>>
>>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Nikl Kelbon via Std-Proposals <std-proposals_at_[hidden]>
>> Gesendet: Di 09.12.2025 05:19
>> Betreff: Re: [std-proposals] vector::push_back must not invalidate past-the-end iterator
>> An: std-proposals_at_[hidden];
>> CC: Nikl Kelbon <kelbonage_at_[hidden]>;
>> Im glad you now asking for a motivation and not asking "what is past the end iterator" or smth what was discussed before
>>
>> In real code i created my container template, so its iterator combines several iterators of its parts. std::vector was one of those parts
>>
>> Then i wrote append(iterator, iterator) and my code sures it is completely right, no reallocation etc etc.
>>
>> But msvc stl implementation find a way to assert it (by storing all .end() iterators in global map under mutex and invalidate them on each push_back)
>>
>> I dont know any other way to code it. Its impossible. THERE ARE NO OTHER WAY!
>>
>> Code:
>>
>>
>> #include <vector>
>>
>> struct mytype {
>> std::vector<int> vec;
>>
>> // in real code it is complex iterator
>> // where vector iterator only part of it
>> using iterator = std::vector<int>::iterator;
>>
>> void append(iterator b, iterator e) {
>> for (; b != e; ++b) { // ASSERTION FAILURE, COMPARING b and e after push_back
>> // again, in real code it complex operation with inserting in my container
>> vec.push_back(*b);
>> }
>> }
>>
>> iterator begin() {
>> return vec.begin();
>> }
>> iterator end() {
>> return vec.end();
>> }
>> };
>>
>> int main() {
>> mytype x;
>> x.vec = {1, 2, 3, 4};
>> x.vec.reserve(100);
>> x.append(x.begin(), x.end());
>> }
>>
>> https://godbolt.org/z/cjfT9vran
>>
>> вт, 9 дек. 2025 г. в 07:18, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>:
>>
>> On Mon, Dec 8, 2025 at 1:56 PM Nikl Kelbon via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>> >
>> > Thats what standard exists for. Standard decides what is ub and what is not ub. How its even may be argument "its ub" in discussion about changing standard?
>>
>> Because your reasoning for why this change is needed is that many
>> users do it regardless of the fact that it's UB, so it makes sense to
>> change it. That is, your proposal is predicated on the idea that this
>> is common code, and therefore if it isn't common code, then it has no
>> motivation.
>>
>> So, what evidence can you provide that people believe that end
>> iterators should work this way? The fact that it can be implemented is
>> not, by itself, sufficient justification for changing the standard.
>> --
>> 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
>>
>>
>> --
>> 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