Designing a client server for the game "chess"

That's right. The fact that your error is popping up is very correct. The error is very simple and without underwater stones.

no match for 'operator <<' in 'out << * game.Game::board'

This is your mistake. What is she talking about? The object itself communicates with us, i.e. class QDataStream. This class tells us "There is no such overloaded function that would be able to record a game object." But this is nonsense, because you yourself overloaded the function that accepts the game object for writing, therefore, it must be recognized. It turns out that this is not nonsense at all, but the whole point is how you implemented the QDataStream & operator << function overload (QDataStream & out, Game & game).

 QDataStream &operator <<(QDataStream &out,Game &game) { out << game; return out; } 

This is your overload. When you write out << * game, the compiler searches for and finds the appropriate function (which you rebooted) and starts executing the code you wrote there. You did not write anything special there, but simply wrote out << game. So the compiler does not know how to do this for "foreign" objects. He again searches for and finds your function, and again stumbles upon the line out << game, etc. etc. In general, you need to overwrite the data that QDataStream understands in the overloaded function according to a certain structure (how to disassemble the Game object into components that the QDataStream understands and write them down) so that you can then consider these same components A certain structure to collect the object game.

Here is a simple example.

 #ifndef SIMPLE_H #define SIMPLE_H #include <QString> #include <QDataStream> class Simple { public: Simple(); Simple(int a_, int b_, QString s_); friend QDataStream &operator<<(QDataStream &out, Simple &obj); friend QDataStream &operator>>(QDataStream &in, Simple &obj); private: int a; int b; QString s; }; #endif // SIMPLE_H 

ccp:

 #include "simple.h" Simple::Simple() { } Simple::Simple(int a_, int b_, QString s_) : a(a_), b(b_), s(s_) { } QDataStream &operator <<(QDataStream &out, Simple &obj) { out << obj.a << obj.b << obj.s; /* если бы я написал, как Вы, "out << obj", то была бы опять ошибка, проверьте. */ return out; } QDataStream &operator >>(QDataStream &in, Simple &obj) { in >> obj.a >> obj.b >> obj.s; return in; } 

And what prevents to do like this?

We declare QByteArray, then in it I use QDataStream we read the length of the class object, storing it say in quint16, then the object itself. We send it all through write. At that end, establish a connection using the readyRead signal.

The documentation says that it is called, not when all the information comes to the socket, but when at least something arrives. And there, already using the same QDataStream, we wait until 16 bits arrive to read the length of the message in quint16, check if everything has arrived, and only then read into the class object.

This is how it looks:

server.cpp

 void Widget::slotSendToClient() { QByteArray arrBlock; QDataStream clientSendStream(&arrBlock, QIODevice::WriteOnly); serverSendStream << quint16(0) << game; clientSendStream.device()->seek(0); clientSendStream << quint16(arrBlock.size() - sizeof(quint16)); tcpSocket->write(arrBlock); messageLineEdit->clear(); } 

client.cpp

 void Widget::slotReadServer() { next_block_size = 0; QTcpSocket *tcpSocket = (QTcpSocket*)sender(); QDataStream serverReadStream(tcpSocket); while(true) { if (!next_block_size) { if (tcpSocket->bytesAvailable() < sizeof(quint16)) { break; } serverReadStream >> next_block_size; } if (tcpSocket->bytesAvailable() < next_block_size) { break; } Game game; serverReadStream >> game; next_block_size = 0; } }