[Qt-creator] QList and QStringList, or qDebug() odd Behaviour?
Victor Sardina
Victor.Sardina at noaa.gov
Wed Mar 24 01:21:12 CET 2010
Guys:
The program works as expected in Debug mode, but it bombs at the end
when running in Release mode...It quits with the message "The program
has unexpectedly finished.", and the reports from the system says:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fff5fbffb75
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
I started to consider going back to "non-dynamic-memory-allocation" mode...
Victor
Victor Sardina wrote:
> John and Tamás:
>
> Indeed...Thank you for the insight on this one. I should have checked
> the pointer part of the problem first.
>
> Thank you so much,
>
> Victor
>
> Tamás Kiss wrote:
>> Let's take a closer look on what's happening in your code (I'll
>> explain it with staNames, of course the case is the same with the
>> other two variables):
>>
>> - staNames is a pointer to a QStringList
>>
>> - staNames[0] happens to be the QStringList your pointer points to,
>> and it's equivalent with the expression (*staNames). This is because
>> in many kinds of expressions an array can be treated as a pointer to
>> its first element. Notice that you've already made a big mistake here,
>> but while i == 0, the expression is valid, just not what you wanted.
>> Also take into account, that when I write "array", I don't mean
>> QStringList, I mean a traditional C array, whose elements are
>> QStringLists. Of course it doesn't exist here.
>>
>> - qDebug << staNames[0] ... orders qDebug to write your whole
>> QStringList out to stderr.
>>
>> - Later, when i == 1, staNames[1] would be the second element of the C
>> array, that is, another QStringList. Of course this is an illegal
>> memory access, and your program dies.
>>
>> - What should you write instead: (*staNames)[i] : this calls
>> QStringList::operator[].
>>
>> - Why is the other form you wrote exactly as wrong as the first one?
>> Because *(staNames + i) means staNames[i] which is the same as above.
>> :) Again, when i == 1, (*staNames + 0) == *staNames, so you write your
>> whole List to stderr. When i == 1, your program dies.
>>
>> Hope this helps.
>>
>> --
>> Tamás
>>
>> 2010/3/23 Victor Sardina <Victor.Sardina at noaa.gov>:
>>> Trolls:
>>>
>>> I have just recently noticed something rather unusual going on with the
>>> behaviour of the "[]" operator for the QList and QStringList objects via
>>> qDebug(). For example:
>>>
>>> for(int i = 0; i != staNames->length(); i++)
>>> { qDebug() << staNames[i] << endl; //->at(i);
>>> qDebug() << staLats[i] << endl; //->at(i);
>>> qDebug() << staLons[i] << endl; //->at(i);
>>> }
>>>
>>> or
>>>
>>> for(int i = 0; i != staNames->length(); i++)
>>> { qDebug() << *(staNames+ i) << endl; //->at(i);
>>> qDebug() << *(staLats + i) << endl; //->at(i);
>>> qDebug() << *(staLons + i) << endl; //->at(i);
>>> }
>>>
>>> will produce a "serialized" output of the three objects (QStringList,
>>> QList<qreal>, and QList<qreal>, with all values in one object followed
>>> by all values in the next, and so on, as though the index "0" retrieves
>>> all values in memory at once, before it crashes once the "i" counter
>>> increments to 1. I allocated all three objects dynamically via operator
>>> new and populated them via "append" (push_back). The interesting thing,
>>> however, has to do with the fact that replacing the call to the "[]"
>>> operator with a call to "at" produces the intended output, namely, all
>>> three values one at a time for each object as the counter increments.
>>>
>>> Can someone provide some insight on the reasons behind the seemingly odd
>>> behaviour (for me at least)?
>>>
>>> Thank you in advance,
>>> Victor
>>>
>>> _______________________________________________
>>> Qt-creator mailing list
>>> Qt-creator at trolltech.com
>>> http://lists.trolltech.com/mailman/listinfo/qt-creator
>>>
>>>
>> _______________________________________________
>> Qt-creator mailing list
>> Qt-creator at trolltech.com
>> http://lists.trolltech.com/mailman/listinfo/qt-creator
>>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-creator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: victor_sardina.vcf
Type: text/x-vcard
Size: 437 bytes
Desc: not available
Url : http://lists.qt-project.org/pipermail/qt-creator-old/attachments/20100323/a7c33966/attachment.vcf
More information about the Qt-creator-old
mailing list