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 <[email protected]>: > 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 > [email protected] > http://lists.trolltech.com/mailman/listinfo/qt-creator > > _______________________________________________ Qt-creator mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-creator
