Re: Should an iterator be valid after appending to a Glib::ustring?

[Krzysztof Piecuch <piecuch protonmail com>]

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 src gmail com

To: gtkmm-list gnome org

On 13 March 2017 at 21:46, Daniel Boles <dboles src 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.