Figuring out how networking, hex, and ascii interact - c++

Question

I've recently been assigned to a C++ project involving information being sent between computers via UDP. When a packet arrives, I have a program which accepts the data and can display it as a raw hexadecimal string. However, I'm struggling to grasp exactly how this whole process is supposed to work. The hex string supposedly contains several fields (e.g. a 4-char array, some float_32s, and some uint_32s).
How do I translate the sections of this string into the correct variable types? The first value, an ASCII title, was simple enough; the first eight chars in the hex string are a hexadecimal representation of an ASCII word (0x45 hex can be translated directly to the capital letter E). But the next value, a 32-bit float, doesn't really make sense to me. What is the relation between the hex value "42 01 33 33" and the float value "32.3" (a given example)?
I'm a bit in over my head here, I feel I'm missing some essential information regarding the way number systems work.

Answer 1

All types in C have a representation (which for most types is defined by a particular implementation). Most C implementations use IEEE 754 for representing the floating types (this may actually be a requirement for C and C++, but from memory it is not). The Wikipedia article explains how the floating types are represented in memory. In most C and C++ implementations, float is a 32-bit type and double is a 64-bit type. Therefore, in these implementations float is 4 bytes wide and double is 8 bytes wide.
Be careful, because the byte order can be different. Some architectures store the floating type in little endian, some in big endian. There is also a Wikipedia article on endianness too.
To copy the bytes to the floating type, you have to make sure that the floating type is the same size as the number of bytes you have, and then you can copy the bytes one-by-one ‘into’ the floating type. Something like this will give you the gist of it:
unsigned char rep[] = { 0x42, 0x01, 0x33, 0x33 };
float someFloat;
if (sizeof(someFloat) == 4)
{
memcpy(&someFloat, rep, sizeof(someFloat));
}
else
{
// throw an exception or something
}
There are other ways of copying the bytes to the floating type, but be careful about ‘breaking the rules’ (type-punning etc.). Also, if the resulting value is incorrect, it may be because the byte order is wrong, and therefore you need to copy the bytes in reverse, so that the 4th byte in the representation is the 1st byte of the float.

Answer 2

If you have a hex value:
42 01 33 33
It is the equivalent of
0100 0010 0000 0001 0011 0011 0011 0011
in binary code.
Now, there is a floating point standard called IEEE 754 which tells you how to format a floating point number into binary or back.
The gist of it is that the first bit is the sign (positive/negative number), the next 8 bits are the exponent and the last 23 are the mantisse. This is how the computer internally saves floating point numbers, since it's only able to store 1's and 0's.
If you add it all together in the way the IEEE specifies you get 32.3.

Answer 3

The exact data format is specified by the protocol used, but the common ways to represent numeric data are:
Unsigned integer: This is actually the simplest. Its typical representation works in principle like our normal decimal system, except that the "digits" are bytes, and can have 256 different values.
If you look at a decimal number like 3127, you see the three digits. The least significant digit is the last one (the 7 in this case). Least significant means that if you change it by 1, you get the minimal change of the value (namely 1). The most significant digit in the example is the 3 at the very left: If you change that one by 1, you make the maximal change of the value, namely a change of 1000. Since there are 10 different digits (0 to 9), the number represented by "3127" is 3*10*10*10 + 1*10*10 + 2*10 + 7. Note that itz is just a convention that the most significant digit comes first; you could also define that the least significant digit comes first, and then this number would be written as "7213".
Now in most encodings, unsigned numbers work exactly the same, except that the "digits" are bytes, and therefore instead of base 10 we have base 256. Also, unlike in decimal numbers, there's no universal convention whether the most significant byte (MSB) or the least significant byte (LSB) comes first; both conventions are used in different protocols or file formats.
For example, in 4-byte (i.e. 32 bit) unsigned int with MSB first (also called big-endian encoding), the value 1000 = 0*256^3 + 0*256^2 + 3*256 + 232 would be represented by the four byte values 0, 0, 3, 232, or hex 00 00 03 E8. For little-endian encoding (LSB first), it would be E8 03 00 00 instead. And as 16 bit integer, it would be just 03 E8 (big endian) or E8 03 (little endian).
For signed integers, the most often used representation is two's complement. Basically it means that if the most significant bit is 1 (i.e. the most significant byte is 128 or larger), the byte sequence doesn't encode the number as written above, but instead the negative number you get by subtracting 2^(bits) from it, where (bits) is the number of bits in the number. For example, in a signed 16-bit int, the sequence FF FF is not 65535 as it would be in 16-bit unsigned int, but rather 65535-2^16=-1. As with unsigned ints, you have to distinguish between big-endian and little-endian. For example, -3 would be FF FD in 16-bit bit endian, but FD FF in 16-bit little endian.
Floating point is quite a bit more complicated; today usually the format specified by IEEE/IEC is used. Basically, floating point numbers are of the form sign*(1.mantissa)*2^exponent, and sign, mantissa and exponent are stored in different subfields. Again, there are little-endian and big-endian forms.