Using QString fails after QMap :: remove

Question

I have the following code:

class NamedObjectContainer { //... QMap<QString, SomeStruct> mUsed; //... }; const StoredObject* NamedObjectContainer::use(const QString& name, const QString& userId) { qDebug()<<userId; mUsed.remove(userId); qDebug()<<userId; //... } 

Here I am trying to remove an item from QMap using the key (userId). The item has been deleted correctly. But surprisingly, it resets the userId print after QMap :: remove.

 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb5b2c6c0 (LWP 24041)] 0xb5fe899c in memcpy () from /lib/i686/nosegneg/libc.so.6 (gdb) where #0 0xb5fe899c in memcpy () from /lib/i686/nosegneg/libc.so.6 #1 0xb7263246 in QString::append () from /home/osmin/stand_cl_dir/Qt4_x86-linux/lib /libQtCore.so.4 #2 0xb72b6641 in ?? () from /home/osmin/stand_cl_dir/Qt4_x86-linux/lib/libQtCore.so.4 #3 0xb72b218b in QTextStream::operator<< () from /home/osmin/stand_cl_dir/Qt4_x86-linux/lib/libQtCore.so.4 #4 0xb6524740 in QDebug::operator<< () from /usr/lib/libqxmlrpc.so.1 #5 0xb62b5cc0 in tabexchange::NamedObjectContainer::use (this=0x9e2fb08, name=@0xbffe85e4 , userId=@0xa12b780 ) at namedcontainer.cpp:208 

What could cause the problem? I am using Qt 4.4.3

Answer 1

Learn more about @TI comments ...

QString is an implicitly generic type . Each new copy from the QString object increases the reference counter under the hood, and when the counter is reset, it is destroyed.

What probably happened here was that there was an initialization that made an instance of QString, passed it as a key, and the card made a copy. (This does not copy the data, but simply increases the total counter.) Then, the initialization procedure destroyed its instance, so the only common instance on the left is the one that is stored on the card, with the total number of shares.

Later, you probably used something like QMap::iterator::key() to get the const link to the string key on the map passed as userId . This would not create a new QString instance to add to the total bill, but rather indicate the one that belongs to the card. Therefore, when the card allows you to move from it ... it was destroyed, and now userId is a dangling link.

(Note: you are not saying that in SomeStruct . But if through it an instance of a suitable line to the key can be reached, which will be destroyed when the value of the SomeStruct card is destroyed, a link to a line like userId can cause a similar problem.)

One implicit sharing of throws in a mix is ​​that sometimes it hides errors of a nature that will become more apparent without implicit sharing. However, this makes the solution "inexpensive": when you retrieve the key for transmission, copy it to the local variable instance ... and pass the link to this variable to this procedure. This does not actually copy the data, but will make userId safe, because there will be another common account supporting it.

This helps to implement a more accessible protocol: passing a reference type to a subprogram should mean that you can guarantee the lifetime of the reference object for the entire execution time of the function that you are calling. If it is ever in doubt, make a copy and pass the link to the copy.

(Note. In the future, try using the Simple, Self Contained, Correct Example with the addition and deletion enabled, it can lead to the fact that you yourself smoke a weapon, and without it we can only make reasonable guesses about the problem ... this can be caused something else in your program completely!)