octacone wrote:P.S. I know what an integer is, but you cannot make letters like A, B, C, D, E, F become an int.
I am not so certain you
do know what an
int is, because you seem to think that they have something to do with the numerals '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', which is not the case. The decimal numerals are just a representation of the abstract concept of an integer, just as a value stored as a string containing hexadecimal digits ('0','1','2','3','4','5','6','7','8','9','A','B','C','D','E','F') is, a string containing binary digits ('0' and '1') is, as a set of differential currents in a circuit (which is what all data in a conventional CPU actually is) is, or a string holding the Roman numerals 'I', 'V', 'X' 'L', C', 'M' is (as zenzizenzicube already stated).
The value of an
int data object representing the decimal value 6 is an sequence of currents which we usually represent as the binary number 0110; but the character '6' is represented on most computers today as the ASCII (or UTF-8) value whose binary representation is 011 0110, which would, if used as an integer instead of a character (because data in memory has no types in stock computers), would have the value 54 decimal, or 0x36 hex, or 066 octal. They represent that same value, but in different ways.
So what you are actually converting, when you convert an int to a string, is a binary value, and you can convert it to any string representation you choose, even the word "six" if you really want. The fact that you input the value as a hex value has no bearing on it once the compiler converts it to an int in the first place.
I suspect that this last point is the real problem that you are having: that you see the value represented in hex in the source code, and somehow think that it is still a hex value once it is compiled. That simply isn't the case: when the compiler's lexical analyzer matches a token that is a numeric literal, it stores the string representation for the value, and pass that around up to some point, but eventually it will convert that token into a binary integer - regardless of whether you wrote it as "0x0A" or "10" or "012", it still becomes the same sequence of currents (not exactly 'on' and 'off', since they are both greater than zero current, but close enough).
Again, the 'binary integer' is itself a representation of an abstract idea, but one which the CPU has specific operations which it can apply to it which manipulate it as if it were the mathematical construct it represents (up to a point). However, the CPU will just as readily apply to that value the instructions for loading an address, sending a value to the I/O bus, or any other opcode that will take a value that size or less. While 'tagged' architectures which check data type consistency do exist, none of the mainstream processors do (most modern ones use tagged memory in the cache memory systems, but not for typechecking), so it is the job of the compiler and the programmer to make sure that the types match, not the CPU.
