Sign in to follow this  
CRACK123

Macros issues

Recommended Posts

CRACK123    235
Hey I have the following code but when I try to use it, it just doesn't seem to work. Could anyone tell me what wrong with it ?

#define INT2FIX(x) (x << 16)
#define FIX2INT(x) (x >> 16)

int main()
{
   ...
   c = INT2FIX(a);
   d = FIX2INT(c)
}

I seem to get c = 0 and d = 0 if I pass a = 1. While I should get 65536 and 1. Any Ideas as to where I could be going wrong. Or I can't use macros like this ? Thanks

Share this post


Link to post
Share on other sites
overflowed_    194
Just tried your code as you had it there, and it works fine. Unless your compiler has int defined differently than mine (VC6) then there should be no problem. Are you sure it's not just a problem with how you're displaying the results?

Share this post


Link to post
Share on other sites
CRACK123    235
Hi,

I am printing it like this, it gives 0 on both occasions :
printf("%d", c);
printf("%d", d);


If I do this however it works fine
printf ("%d", FIX2INT(a));

Thanks

Share this post


Link to post
Share on other sites
overflowed_    194
Aside from problems with your compiler (unlikely), there's no reason the code you posted shouldn't work. So there's gotta be something else in the program affecting the result.

The program I tested it with is:


#include <stdio.h>
#include <conio.h>

#define INT2FIX(x) (x << 16)
#define FIX2INT(x) (x >> 16)
typedef int GLfixed;

int main(int argc, char *argv[]) {
GLfixed a,c,d;
a = 1;

c = INT2FIX(a);
d = FIX2INT(c);

printf("%d\n", c);
printf("%d\n", d);

getch();

return 1;
}



Try that and see what you get.

Share this post


Link to post
Share on other sites
I'd make it
#define INT2FIX(x) ((x)<<16)
etc.

for extra safety, so you can do
INT2FIX(a+1);

without it evaluating as (a+1<<16) which I think is (a + 65536) due to weird precedence of the shift operators.

Share this post


Link to post
Share on other sites
doynax    850
Quote:
Original post by Paradigm Shifter
without it evaluating as (a+1<<16) which I think is (a + 65536) due to weird precedence of the shift operators.

Shouldn't be a problem since + has higher priority than <<.
Still a good idea to though, otherwise you'll get into trouble with most logic/bitwise operators.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this