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

[John Vilburn]

When you declare staNames as

QStringList* staNames;

then standard C++ says that the statement

staNames[0]

 is equivalent to

*staNames

Which means that in your code the line:

qDebug() << staNames[0];

is asking to dump the entire QStringList. To get the first string in the list using [] syntax you would have to do:

qDebug() << (*staNames)[0];

Hope that clears things up.
Aloha,
John

On Mar 23, 2010, at 1:12 PM, Victor Sardina wrote:

> 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
>> 
> 
> <victor_sardina.vcf>_______________________________________________
> Qt-creator mailing list
> Qt-creator at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-creator