Seite 1 von 1

QDataStream .atEnd()

Verfasst: 31. Oktober 2011 11:53
von DBGTMaster
Hallo,

ich bekomme von einem QDataStream eine X- Anzahl von QByteArray Elemeten. Diese möchte ich mit einer Schleife auslesen, und zwar wie folgt:

Code: Alles auswählen

    while (tcpCommands->hasNext()) {
        QPair<QByteArray, QByteArray> pair = tcpCommands->next();

        qDebug() << pair;
    }
Dann noch die 2 Methoden:

Code: Alles auswählen

bool TcpCommand_system_getAllTcpCommands::hasNext() const {
    return _dataStream.status() == QDataStream::Ok;
}

QPair<QByteArray, QByteArray> TcpCommand_system_getAllTcpCommands::next() {

    QPair <QByteArray, QByteArray> pair;
    _dataStream >> pair.first;
    _dataStream >> pair.second;

    return pair;
}
Problem ist, dass immer am Ende ein leeres QPair ausgegeben wird:
QPair("loggedInUser","getUserColumn")
QPair("main","userLogin")
QPair("main","connectTcp")
QPair("main","serverVersion")
QPair("system","getAllTcpCommands")
QPair("","")
Problem wird wohl das sein, dass QDataStream.atEnd() erst das Ende des Lesens zurückgibt, wenn das lesen bereits fehlgeschlagen ist, und nicht davor...

Workaround wäre:

Code: Alles auswählen

while (true) {
        QPair<QByteArray, QByteArray> pair = tcpCommands->next();
        if (!tcpCommands->hasNext()) break;

        qDebug() << pair;
    }
Nur gefällt mir dieser Code- Style nicht...

Jemand eine Idee, wie ich das Problem lösen kann??

lg

Re: QDataStream .atEnd()

Verfasst: 2. November 2011 07:35
von almboa

Code: Alles auswählen

while (!tcpCommands.atEnd())
{
   tcpCommands.next();
   // process
}

Re: QDataStream .atEnd()

Verfasst: 2. November 2011 17:45
von DBGTMaster
atEnd() gibt erst true zurück, wenn das lesen bereits fehlgeschlagen ist... und genau da ist das Problem ..

Re: QDataStream .atEnd()

Verfasst: 2. November 2011 18:09
von solarix
kann ich nicht bestätigen.

das:

Code: Alles auswählen

#include <QDataStream>
#include <QByteArray>
#include <QString>
#include <QDebug>

int main()
{
  QByteArray data;

  QDataStream writer(&data,QIODevice::WriteOnly);
  writer << QString("eins") << QString("zwei") << QString("drei");

  QDataStream reader(data);
  while (!reader.atEnd()) {
    QString str;
    reader >> str;
    qDebug() << str;
  }
  return 0;
}
liefert bei mir genau die drei erwarteten Strings und kein viertes (leeres) Element. Ich vermute (anhand deiner Namensgebung) eher, dass du mit einem unvollständigen TCP-Stream arbeitest (da sind noch nicht alle Daten angekommen).

hth..

Re: QDataStream .atEnd()

Verfasst: 2. November 2011 18:48
von DBGTMaster
Nmmh... werd ich morgen wohl nochmals testen, aber es sind definitiv alle Daten vom Tcp- Stream angekommen...

Ich melde mich :)

Re: QDataStream .atEnd()

Verfasst: 3. November 2011 10:39
von DBGTMaster
Neuer Tag, und alles funktioniert wunderbar :) ...

Habe gerade festgestellt, dass ich mit "return _dataStream.status() == QDataStream::Ok;" anstatt von atEnd() überprüft habe, und status() liefert so lange ok, bis das lesen fehlgeschlagen ist...

danke!

Re: QDataStream .atEnd()

Verfasst: 8. November 2011 09:55
von RHBaum
Neuer Tag, und alles funktioniert wunderbar
Naja ich waere da skeptisch .... ^^

wichtig, streams unterscheiden sich anhand ihrer "Optionen" Ihrer Features.

so hat z.b. ein File ein "ende", eine TCP verbindung eher nicht. Wenn doch, dann wird es "künstlich" erzeugt, und ist eigentlich wertlos ...
Ne verbindung wird eher geschlossen ...

eigentlich zeichnen sich Protokolle, die ueber reine Stream-Serbindungen gehen , durch absolute Status und Positionsunabhaengigkeit aus. Das heisst diese Protokolle steuern sich selber.
So schickt man z.b. längenangaben mit rueber, damit die gegenstelle genau weiss, wenn sie alle hat.
Ne TCP verbindung kann auch abbrechen, wenn was unvorhergesehenes passiert.
Wie soll nen Programm das mitbekommen, wenn es nur die info gibt, das die connection geschlossen wird ? Und ich denk scho das es ne wesentliche Info für das Programm ist, ob die "Daten nu zuende " sind, oder ob einfach nur die connection abgewuergt wurde ...

Ciao ...