Thread: hex math

Hi
I was presented with the following in a job interview and was asked to provide the output.
Please help me learn from this.

Code:

int main()
{
    char buff[]={ 0x11,0x11,0x11,0x11,0x22,0x22,0x22,0x22,0x33,0x33,0x33,0x33};
    char* pEnd = buff + sizeof(buff) -1;
    long * plong = buff;
    short* pshort = buff;

    for(; plong<pEnd; plong++)
        printf("0x%X\n", plong);

    for(; pshort<pEnd; pshort++)
        printf("0x%X\n", pshort);

    return 0;
}

I now realize that short is 2 bytes and long is 4 bytes.
how does that change on other platforms?

the output is:
0xBFA29F44
0xBFA29F48
0xBFA29F4C
0xBFA29F44
0xBFA29F46
0xBFA29F48
0xBFA29F4A
0xBFA29F4C
0xBFA29F4E
I don't understand why?

Thanks Mats for the explanation.
can anyone please help me understand how the output came to be what it is?

Originally Posted by kroiz

Thanks Mats for the explanation.
can anyone please help me understand how the output came to be what it is?

What part of matsp's explanation did you not understand?

I understand the size of the long and short but I don't understand how making them point to the char array cause that output.

Originally Posted by King Mir

I think you want to write printf("0x%X\n", *plong) and printf("0x%X\n", *pshort).

Wonderful, now it all makes sense.
Thanks a lot.

Who knew that taking 0x11 and shifting it left 8 times would produce 0x1100. Damn hex math...
oh well maybe next job interview....

Originally Posted by kroiz

Who knew that taking 0x11 and shifting it left 8 times would produce 0x1100. Damn hex math...
oh well maybe next job interview....

Most people. You may want to think about learning basic stuff like this before you try to go in an get a job programming.

Originally Posted by MeTh0Dz

Most people. You may want to think about learning basic stuff like this before you try to go in an get a job programming.

(-: I've been programming very successfully for 8 years w/o it.

Originally Posted by DaveH

This problem didn't have much to do with hex knowledge, but about incrementing pointers to different sized things, along a character buffer.

that is the easy part, at least for me.
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.

Originally Posted by kroiz

that is the easy part, at least for me.
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".

Originally Posted by tabstop

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?

Originally Posted by kroiz

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.