Yeah, totally not cross-platform.
There are a couple of reasons.
1. Integer sizes.
Different computers have different sizes for particular types of integer. For example, on the PC, a "short" is typically 16-bit, and a "long" is 32-bit. On a PS2, a "short" is 32-bit, and a "long" is 64-bit. Other platforms have other lengths. This means that your classes will likely be different sizes on different platforms.
For this reason, network packets are typically not built using "short" or "long" variables; instead, you use the special networking types:
int16_t (16-bit integer)
uint16_t (16-bit unsigned integer)
int32_t (32-bit integer)
uint32_t (32-bit unsigned integer)
...etc.
But you'll almost certainly find regular 'short' and 'long' and 'int' variables in your classes, and those mean that the classes on different platforms are not likely to match.
2. Endianness.
Different computers represent integers in different ways. For example, Intel-based computers are "little endian", whereas PowerPC-based computers are "big endian". It's basically about the order of the bytes within the number. If we pretend that decimal digits are bytes, then a big-endian computer would store the number one-hundred and twenty-seven as "127". By contrast, a little-endian computer would store it as "721". For this reason, you can't simply copy the memory directly from one computer to another; they store their values differently!
3. Padding
Compilers pad data structures, to arrange values in memory in the best way. Here's a typical example of what you might see on a standard PC:
struct
{
char valueA; // 1 byte, stored in byte 0.
int valueB; // 4 bytes, stored in bytes 4-7 (1-3 are padding, to make sure that valueB is four-byte aligned)
char valueC; // 1 byte, stored in byte 8
};
sizeof(struct) == 12. Padding added to bring the struct out to a four-byte boundary (to make it pack nicely in case somebody puts it into an array)
But different computers pad their storage in different ways. The locations of data within a struct on one type of computer won't necessarily match those on another platform. Plus, depending on the padding, a struct or class can actually be different sizes on different platforms!
4. vtables
Since you mention that it's a class, it's worth mentioning that any class with virtual functions will have some extra data attached to it, which includes pointers to the code containing those functions. Needless to say, overwriting those pointers on another computer is going to be Extremely Bad.
5. MTU
Since you mention that you're using 'sendTo' which transmits data using UDP, it's worth mentioning that UDP has a "Maximum Transmission Unit"; the maximum amount of data that you can send in one UDP packet. The fun thing about this is that it's going to be different depending upon the source and destination, based upon the space required for routing information used by the network hardware between them. Technically, MTU can be as high as about 1500 bytes, but you really shouldn't rely on having more than 1300 bytes in total. If your class is larger than about 1300 bytes, you'll find that it'll often not be received by the intended recipient, as the routers between you and them will just silently drop the too-large packet.
So what do you do?
Well, you really need to pack your individual pieces of data into a cross-platform blob of data, which can be done relatively easily using functions like memcpy(). You need to do this yourself, to keep your compiler from laying out data in what it considers to be a "smart" way. Something like this:
void *buffer[120];
int posInBuffer = 0;
memcpy( buffer[posInBuffer], &valueA, sizeof(valueA) );
posInBuffer += valueA;
memcpy( buffer[posInBuffer], &valueB, sizeof(valueB) );
posInBuffer += valueB;
...etc. And you can copy data out of the buffer and back into your values, to decode a received packet.
Now, that's not quite enough, though; you also have to deal with endianness, which I mentioned in point 2 above. The internet standard is to transmit all data in big-endian format, and Berkeley sockets provides a standard set of functions to help convert your data to and from big-endian format. These functions are:
ntohl(uint32_t) // convert a 32-bit number from Network-format (big-endian) to Host-format (big-endian or little-endian, whichever is appropriate for the computer being run on)
htonl(uint32_t) // convert a 32-bit number from Host-format (big-endian or little-endian) to Network-format (big-endian).
ntohs(uint16_t) // convert a 16-bit number from Network-format to Host-format
htons(uint16_t) // convert a 16-bit number from Host-format to Network-format
Hope this explanation about why you can't naively send a class directly over the network makes sense. You really need to manually convert and pack the specific data you want to synchronise into network-order packets, and then unpack it into native data on the receiving side.
Developer
