What about ustring.end() iterator? I think it's obvious that it's invalidated
each time we change the string's length (unless it's done in some *very clever*
way).
It's a thing no reserve()-ation can help.
-------- Original Message --------
Subject: Re: Should an iterator be valid after appending to a Glib::ustring?
Local Time: 13 marca 2017 10:50 PM
UTC Time: 13 marca 2017 21:50
From: dboles....@gmail.com
To: gtkmm-list@gnome.org
On 13 March 2017 at 21:46, Daniel Boles <dboles....@gmail.com> wrote:
This is a pretty obvious "no". If the operation can cause a reallocation,
that's a very strong hint, so if the container does not explicitly state that
it does NOT invalidate iterators.... then it does
I really meant 'increase the capacity', not 'reallocation', if we use
'reallocation' in the sense of moving existing elements, not just allocating
other memory for new ones. So reallocation in this sense should always
invalidate iterators. And since ustring (and std::string) is a random-access
container, it must have contiguous memory, so any increase in capacity must
cause a reallocation. So, any insert/append or anything else that adds elements.
but there's a point: if you had previously reserve()d enough capacity, beyond
the current size, for the insert point and length, then as long as you stay
within the capacity you had, your iterators should remain valid, as
reallocation is guaranteed not to occur in such cases.
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
