[Qt-creator] QList and QStringList, or qDebug() odd Behaviour?

[Victor Sardina]

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
> 

-------------- 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/45d99989/attachment.vcf