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



It is a general concept of C++ that iterators are invalidated by various modifying operations, and the API should usually specify which operations do and do not invalidate iterators.


In this case, if ustring itself does not stipulate, you should check the Standard C++ documentation for std::string - as ustring is mostly a thin wrapper around that giving Unicode semantics. However,

Specifically appended to or modified at or beyond where the
iterator points.  Especially if appending to the string causes the
underlying bytes to be relocated to a larger allocation.  I didn't
obviously see this mentioned in the documentation.

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. Again, ustring will follow std::string here, where I know this not to be valid.


I though it might be valid because the iterator appears to be
implemented using a pointer difference type.  However the following
small test program fails with:

Well, it's a difference _from a particular base address_, isn't it? If reallocation occurs, that address changes, so the iterator now offsets into memory that no longer belongs to its instance.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]