reinterpret_cast for received tcp packets
-
@Christian-Ehrlicher The interface is well documented and both sites agreed to it. So there will be no change to that without further discussion between me and our partner :)
-
@Redman said in reinterpret_cast for received tcp packets:
The interface is well documented and both sites agreed to it. So there will be no change to that
-
@Redman said in reinterpret_cast for received tcp packets:
The interface is well documented and both sites agreed to it.
Then you would not have asked any of the questions above nor any problems wrt connecting to another process.
-
@Christian-Ehrlicher And you live in a perfect world where no problems occur? :)
-
@Redman said in reinterpret_cast for received tcp packets:
And you live in a perfect world where no problems occur?
No, but your questions/problem revealed a basic lack of a "well documented" interface.
-
@Redman said in reinterpret_cast for received tcp packets:
01:00:00:00:01:00:01:00:00:00:01:00:00:00:00:00:00:00:01:00:00:00
This is what you'd expect for a packed struct (as you have figures out). It worked before because both sides were using C++ and so both sides were not using packed structs (so much about the "well defined protocol").
In order to not have that problem @J-Hilk is right to write a constructor expecting a QByteArray. For sending you should also pack the members into a QByteArray yourself. This also makes you immune to the order of the members (which is only guaranteed by a very, very recent C++ standard). It is also common practice to order members from biggest to smallest, so you can adhere to alignment rules and still get the most compact representation. This would also solve your problem (on the C++ side; I don't know Python) that you don't have to explicitly pack the struct.
