Are you sure this is a Qt related problem?From what I see it is the STL runtime of MSVC that asserts... You are probably doing something you shouldn't be doing with the string.
Are you sure this is a Qt related problem?From what I see it is the STL runtime of MSVC that asserts... You are probably doing something you shouldn't be doing with the string.
It's this function thats the trigger:
QString::toStdWString()
it returns std::basic_string<wchar_t> which it creates inside - and in the destructor of the temporary object i fail.
Again it's something that doesn't happen in the release. so i believe the code is ok,
and has some mistaken Assertion in debug.
it's rather a straightforward thing so i thought other here might be familiar with it.
hed
QString just creates an object and doesn't care about it any more. Take a look at the stack trace you provided - there is not a single reference to Qt code there.
Because release applications don't assert. But it doesn't mean the code is correct. If the assert is there, it's because of a reason, I think it is safe to assume STL implementors knew what they were doing.Again it's something that doesn't happen in the release. so i believe the code is ok,
and has some mistaken Assertion in debug.
i still think it is a QT problem - only now i can be more specific. ;-)
The fact i have a crash just means something interenally is not stable inside the QString object.
here is my test program:
Qt Code:
CString test2 = test.toStdString().c_str();To copy to clipboard, switch view to plain text mode
everything works ok.
Qt Code:
CString test2 = test.toStdString().c_str();To copy to clipboard, switch view to plain text mode
third line fails because of the size of the arg.
Can you reproduce it?
(My environment is - Windows + MFC + ATL)
Anyone familiar with it?
hed
Last edited by jpn; 30th January 2008 at 08:49. Reason: changed [i] to [code]
You clearly have an invalid code. It's the same like if you wrote:
Second line of the above code is invalid because data() returns a pointer to internal data of the byte array that gets destroyed immediately as it is a temporary object. From what I understand you are doing exactly the same in your code and Qt has nothing to do with it.Qt Code:
char *cstr = str.toAscii().data(); printf("%s\n", cstr);To copy to clipboard, switch view to plain text mode
it depends when the temporary variable is being killed.
the line:
CString test2 = test.toStdString().c_str();
copy the data before the temporary object is being killed and its memory released.
anyway, to better show my problem:
take a look at the following code:
Qt Code:
test.toStdString();To copy to clipboard, switch view to plain text mode
third line fails.
it's the destructor of the temprary object that fails.
Again -
there is a good chance i'm doing something wrong:
only i don't see what.
hed.
The temporary object gets destroyed immediately after the statement it was created in is finished.
If the std::strnig object is valid Qt has nothing more to do with it. Are you by any chance using VS6 to compile your project?
That's imho the correct question
Keep in mind that std::string and std::wstring are different regarding whether you compile the code in Debug or Release mode in every msvc version. So when you mix e.g. Release Qt and Debug Program or vice versa, you'll encounter a crash. But your linker should warn you about such things.
But why you need crappy std::string/wstring at all?
To add to this growing post, I have run into similar issues when using std::string on VS2005 in debug mode. When the scope destructors are called the program aborts in the ~Tidy( ) function. This is only using std::strings and no QStrings what-so-ever. However, when I ran the same code on VS2003 it works just fine. The program also runs fine in release mode. I definatly believe it has something with VS implementation of std::string in converting it into a c_str( ). I am using Qt v4.3.0 as well, but I have to link to data libraries that return std::string's so dont assume that all people can get away from "crappy std::string/wstring". We have to make due.
I am using .Net 2003
and in my case it was a Debug/Release mixing
i was compiling in debug mode while using the release QT libraries.
when changing to the debug libraries everything returned to behave normal
hed
Bookmarks