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

[Victor Sardina]

Hi Andre:

The definition of the objects in question as follows

QStringList* staNames;
QList<qreal>* staLats;
QList<qreal>* staLons;

which I allocate in a constructor as:

staNames = new StringList;
staLats  = new QList<qreal>;
staLons  = new QList<qreal>;

and destroy in the destructor once done with everything. I populate each
list from a file using the "append" member function, nothing unusual here:

staName->append(QString const&);
staLats->append(qreal const&);
staLons->append(qreal const&);

This loop:

for(int i = 0; i != staNames->length(); i++)
{  qDebug() << staNames[i];
   qDebug() << staLats[i];
   qDebug() << staLons[i];
}

should simply list the contents of the objects in order (404 of them in
memory), but it doesn't. The code simply bombs, even if you never reach
index i=1 and instead just use:

{  qDebug() << staNames[0];
   qDebug() << staLats[0];
   qDebug() << staLons[0];
}

In both cases the output looks as shown below:

("AAK", "AAM", "ABKT", "ABPO", "ABVI", "ADK", "AFI", "AGPR", "AHID",
"AK01", "AKT", "AKUT", "ANMO", "ANTO", "ANWB", "AOPR", "ARA0", "ARE0",
...more station names here...)
(42.639, 42.3012, 37.9304, -19.0174, 18.7297, 51.8837, -13.9093, 18.47,
42.765, 50.6911, 54.16, 54.1352, 34.9461, 39.8689, 17.6685, 18.35,
69.5349, 69.5348, 56.4302, 133.951, -7.9327...more latitude values here...)
(74.494, -83.6567, 58.1189, 47.227, -64.3325, -176.684, -171.777,
-67.11, -111.1, 29.2131, -165.78, -165.772, -106.457, 32.7936, -61.7856,
-66.75, 25.5058...more longitude values here...)

I find that odd, as that means that you cannot manipulate the contents
of those objects in a regular loop using their indexes? I haven't tried
using iterators, but as they allow you to reference one object at the
time, back and forth, this turns quite inconvenient an inefficient
unless someone has a rational for that behaviour. The "at" does what the
code appears to mean, but the "[]" operator doesn't.

I don't attached the whole code due to its length. As a matter of fact,
that fragment constitutes just a tiny part of the whole application, but
it really bothers me that you don't get what you expect.

I don't know if if has something to do with qDebug() or not, but I just
find it puzzling and counter-intuitive. I haven't tried this under
Linux, only Mac for now, but will do so maybe tomorrow unless you or
someone else provides some rational for that behaviour.

Thank you for your assistance,

Victor

Andre Poenitz wrote:
> On Tue, Mar 23, 2010 at 10:07:07AM -1000, Victor Sardina wrote:
>> 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);
>> }
> 
> What is "staNames"? A pointer to a single QStringList?
> Then staNames + 1 would be out-of-bounds...
>  
>> 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)?
> 
> Assuming you run into undefined behaviour, "randomness" is all you might
> expect - and it's hard to tell from the snippet what you are doing
> exactly. Minimal but self-contained test code usually helps finding
> explanations.
> 
> The fact that at() does not detach on shared objects while [] does might
> contribute to the observed difference.
> 
> Andre'
> _______________________________________________
> 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/dd0b9604/attachment.vcf