wxWidgets Discussion Forum

The attached C++ program crashes rather horribly on my multi core system. It passes all wxStrings by VALUE so there should be no issues with concurrency. However, the underlying wxStringData object with reference counters is not thread safe. Note: Replacing the use of wxString with std::string in th...

The fact that wxString implements a shared buffer is an internal implementation detail that shouldn't be forced upon the application developer that uses wxString objects. ...etc... I agree, my suggestion was along the lines of, "since it's explicitly stated that wxWidgets (including wxString) ...

The point is that the shared pointer implemented by wxString should be thread safe - not the contents of the data that is being pointed to. From reading this discussion, it would appear that the pointer returned by c_str() is safe so long as the original wxString wasn't sharing its data buffer with...

The two mentioned problems are not real technical problems but conceptual issues and they can be avoided by using synchronization primitives (wxCriticalSection, etc) in user code. My opinion is not necessary to add any synchronization to wxString or other primitives like vectors, maps, etc, because...

Ok, I'm sorry. I posted my initial message under a false understanding of the problem. So lets reset. The topic that wxStrings are not thread safe is still the issue. The problem is the description. Here is a symplified scenario. wxString str1 = "A really really big string"; wxStirng str2 ...

megabyte wrote:c_str does not modify any internal variables

Code: Select all

wxChar *m_pchData;
...
const wxChar* c_str() const { return m_pchData; }

Your right. The problem is with mb_str() or casting the wxString to (const char*). The scenario is the same.

Hm. Then it shows a flaw in wxString's implementation. But I doubt that's possible as c_str is a const member function, and I doubt there are mutable member variables. Then again, you may not be using wx's wxString, as you may have defined wxUSE_STL to 1 and thus use std::string as the "main&q...

Because as thread A reads from the string using c_str(), thread B may be writing to the string. Granted c_str is a const-member function, thread B changed the data as A is reading from it, which basically will result in undefined behaviour. Joel No! This is not the case. Thread A initializes a stri...

Actually I just want to have the following. printf(_T("%s\n"), str.c_str()); The c_str() member is essentially a read accessor. It doesn't change the essential contents of the wxString object. (I.E. The value of of str should be the same before and after the call). Why should I have to syn...

This is essentially what we had to do. The fact that we had to do it was a big blow to the desire of several of our engineers in using wxWidgets. In fact a lot of the development using wxWidgets was stopped because of this. It took weeks to undo lots of development. It would be really nice if the re...

I really like wxStrings. They provide a lot more functionality over std::string objects. We tried to use wsStrings in situations where multiple threads made read access to a single wxString. The result was catastrophe. Apparently the wxString keeps a local copy of a multibyte version of the string t...