that is the easy part, at least for me.Originally Posted by DaveH
I just did not did not realise that putting 0x11 in the first byte of a short and 0x11 in the second byte produce 0x1111 and that *is* hex math. it does not work this way for base 10.
and to tell the truth I doubt that base on this question you can judge a candidate match for a c++ job.
That's not so much hex math as it is "eight bits is a byte".
No, it was a long not a byte and the number for the output was hex and would look differently with decimals, and don't forget this is a test without a computer or a calculator - just a pencil and a paper.
Change the the formated string in the printf from "0x%X\n" to "%d\n" and tell me - can you predict the result w/o a calculator or a computer?
What I mean is that realizing that the answer is 0x1111 is not "hex math" but "there are eight bits in a byte" -- you can solve the problem if and only if you know that there are eight bits in a byte (and also, I suppose, that 0x11 is eight bits long).
Without a calculator? It wouldn't take long to turn 0x11111111 into decimal (it wouldn't be fun, but you could do it); start with one and repeat (times 16 plus 1) seven times for Horner's method. If you mean I had decimals, then same idea but (times 256 plus new number) each time through.
Yes it is, because if you take a long and you put in every byte, a hex number, only with hex you would get a number that looks like all the hex numbers "concatenated". that is just a property of hex.
here is an exercise for you: take the decimal number 2 and put it in every one of the 8 bytes of a long. what a decimal number would this long carry?
now do the same exercise but instead of decimal do it with hexadecimal.
Do you see how simple it suddenly became?
That is because of the property of hexadecimal numbers that you can just put one next to the other and get a "concatenated" number.
I only needed to know this to successfully write the solution and if you would ask that exercise like 10 years ago when I was in collage, I would solve it with ease. but due to lack of usefulness (for me) the hex math slipped my mind.
I am pretty sure I wont forget that now.
Last edited by kroiz; 01-20-2009 at 12:44 PM.
I'm still at a loss as to what shifting 0x11 has to do with this problem. The only thing you are printing is the value of the pointers, the address they point to. The output will be different on different computers because the address of buff[] will be different on them. Basically, the interviewers wanted you to demonstrate that you understood how the pointers would move through the buffer.
* * indicates which address the pointer is pointing to.
For the long * :
1. *0x11*, 0x11, 0x11, 0x11, 0x22, 0x22, 0x22, 0x22, 0x33, 0x33, 0x33, 0x33
2. 0x11, 0x11, 0x11, 0x11, *0x22*, 0x22, 0x22, 0x22, 0x33, 0x33, 0x33, 0x33
3. 0x11, 0x11, 0x11, 0x11, 0x22, 0x22, 0x22, 0x22, *0x33*, 0x33, 0x33, 0x33
for the short * :
1.*0x11*, 0x11, 0x11, 0x11, 0x22, 0x22, 0x22, 0x22, 0x33, 0x33, 0x33, 0x33
2. 0x11, 0x11, *0x11*, 0x11, 0x22, 0x22, 0x22, 0x22, 0x33, 0x33, 0x33, 0x33
3. 0x11, 0x11, 0x11, 0x11, *0x22*, 0x22, 0x22, 0x22, 0x33, 0x33, 0x33, 0x33
4. 0x11, 0x11, 0x11, 0x11, 0x22, 0x22, *0x22*, 0x22, 0x33, 0x33, 0x33, 0x33
5. 0x11, 0x11, 0x11, 0x11, 0x22, 0x22, 0x22, 0x22, *0x33*, 0x33, 0x33, 0x33
6. 0x11, 0x11, 0x11, 0x11, 0x22, 0x22, 0x22, 0x22, 0x33, 0x33, *0x33*, 0x33
From your output given :
the output is:
0xBFA29F44 --> long 1
0xBFA29F48 --> long 2
0xBFA29F4C --> long 3
0xBFA29F44 --> short 1. Notice this is the same as long 1 because plong and pshort were initially at the start of buff
0xBFA29F46 --> short 2
0xBFA29F48 --> short 3 Same as long 2
0xBFA29F4A --> short 4
0xBFA29F4C --> short 5 Same as long 3
0xBFA29F4E --> short 6
Last edited by DaveH; 01-20-2009 at 01:29 PM.
No, look at post #6. /:
So the original code you provide was wrong? I was going by that piece of code. I assume that is the code the interviewers gave you. Was it not? Did they want you to print *plong and *pshort? If so, then I stand corrected. But I still think they probably wanted you to show knowledge of what I explained with the movement of the pointers.
Yes the code in the first post is wrong, it is not what the interviewer game me.
They wanted the print of *plong and *pshort.
and yes in order to solve it correctly I had to know the size of the pointers and how they move and that was part of what they wanted to know.
It just weird to me that they also wanted me to know this thing about hex, that w/o it I could not solve the exercise.
Especially due to the fact that it was not the kind of interview that the interviewer is a technical person that after you finish the test, goes over the test with you to see how you think.
It was a test given to me by a hr lady to check if I can proceed to the next stage.
But whatever, I just wanted to learn from it and go on to the next interview.
It's not some special property of hex. It boils down to the compatibility between binary and hex -- the logarithm of 16 is divisible by the logarithm of 2. In other words, a whole number of hex digits can be represented by a whole number of binary digits.
Octal is the same way, with each digit of octal being equivalent to 3 binary digits.
There is nothing special about any numbering system, whether it is decimal, octal, hex, binary...
The idea of "hexadecimal math" makes about as much sense as "Australian math."
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
I could say that you are absolutely right but for the sake of argument...
I did not say that hex math, is a subset of math or a superset of math or a different set of math - just that it is math that involves hex. nor did I said that it is a unique property of hex. just a property.
But I do understand it better now thanks to your explanasion.
