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