On 02/08/18 19:01, Jeff Young wrote:
> I finally caught a long-standing but very infrequent crash in the
> debugger. It’s somewhat harrowing.
>
> wxString keeps multiple iterators on a string up-to-date with regard to
> editing. It keeps them in a linked list. If you reference a global
>
Interesting. I also found this:
#if wxUSE_UNICODE_UTF8
// NB: In UTF-8 build, (non-const) iterator needs to keep reference
// to the underlying wxStringImpl, because UTF-8 is variable-length
// encoding and changing the value pointer to by an iterator (using
// its operator*)
Hi Jeff-
Good find. I note here (http://docs.wxwidgets.org/3.0/classwx_string.html)
that the use of wxString is explicitly discouraged:
"While the use of wxString is unavoidable in wxWidgets program, you are
encouraged to use the standard string classes std::string or std::wstring
in your
PS: I also have a strange sense of deja vue. Did I discover this earlier and
forget already, or is my mind just playing tricks on me?
> On 2 Aug 2018, at 18:01, Jeff Young wrote:
>
> I finally caught a long-standing but very infrequent crash in the debugger.
> It’s somewhat harrowing.
>
>
I finally caught a long-standing but very infrequent crash in the debugger.
It’s somewhat harrowing.
wxString keeps multiple iterators on a string up-to-date with regard to
editing. It keeps them in a linked list. If you reference a global string in
a thread (even in a const manner, such as
5 matches
Mail list logo