#define

[Unregistered]

would the following code be valid?

#define CUBE(m) m*m*m       
#define REM(y) (y%2)
#define ANSWER(x,y) ((x*y)<10?1:0)

the purpose of the 3 macros

1) Cube of m
2) give remainder of y when y divided by 2
3) give 1 if product of x and y is less than 10, otherwise give 0


the third one in particular is not making sense to me
do I have the identifier set up ok ?? eg. ANSWER(x,y)

[Unregistered]

Yep. They're correct. However: It is always a Good Idea(TM) to surround the arguments of any macro in parenthesis. The reason for this is something like:

#define MYMACRO(x,y) x*y+32

And if I call it with:

MYMACRO( 4*.24+14/(2-243*15)-4/16+3*6, 6 );

The call is valid, but you may not get the results you want. (In this case, you may. It is just an example.)

Thus:

#define MYMACRO(x,y) (x)*(y)+32

Is much better.

Your macros should be fine.


Quzah.

[doubleanti]

right idea...

isolate each token in the define, and isolate the entire define...

eg...

#define BLAH_FOO(x,y,z) ((z) + (x) * (y))

[Unregistered]

#define CUBE(m)  (m*m*m)       
#define REM(y)   ((y)%(2))
#define ANSWER(x,y)   ((x*y)<(10)?(1): (0))

Is this better???

What arguments would make the macros fail??

(a) if you separate the m's and *'s with whitespace, does that mess things up? I would think that with or without parentheses, this macro would work. However, can you use the POW (power) function in a macro???

(b) definitely need parentheses here because y could be any expression and you need the parantheses to make it it's own token, right???

(c) this one is the conditional operator and I don't know how to explain what would make this fail, any ideas?

[QuestionC]

I better point out that this first implementation shows the errors, it is not meant to be correct.

#define CUBE(m)  (m*m*m)       
#define REM(y)   ((y)%(2))
#define ANSWER(x,y)   ((x*y)<(10)?(1): (0))
main ()
{
 CUBE(3); // (3 * 3 * 3) = 27, correct.
 CUBE(3 + 2); // (3 + 2 * 3 + 2 * 3 + 2) = 17, wrong
 REM(5); // ((5)%(2)) = 1, right
 REM(4 + 1); // ((4 + 1)%(2)) = 1, right
 ANSWER(5, 2); // ((4*2)<(10)?(1):(0)) = 0, right
 ANSWER(4 + 1, 2); // ((5 + 1 * 2)<(10)?(1):(0))=1, wrong
}

There isn't any reason to use things like (2) or (10) in your macros, because you know very well what those will evaluate to. Each variable of a macro should be parenthesized however. You were right to put parenthesis around the entire expression however.

How, for example, cube should be done is like this...

#define CUBE(m) ((m) * (m) * (m))
main ()
{
 CUBE(3); // ((3) * (3) * (3)) = 27, correct.
 CUBE(3 + 2); // ((3 + 2) * (3 + 2) * (3 + 2)) = 125, correct.
}

As a final note, in macros like CUBE, it will still be foiled by using things like CUBE(x++), although getting around that is way too complicated for this post. Also, you only need to put parenthesis around arguments which you do not know what they will evaluate to, so please get rid of the parenthesis around constants, as it only makes it harder to read.

And oh yea, adding whitespace to the macros shouldn't affect how they evaluate at all.

[Unregistered]

I am not understanding recursive functions, especially when called in a compound statement


here's a sample program with void function.
I don't know what the function does.
I am getting a segFault and don't know why.
And I need to get a full understanding of the recursive function.
HOW DOES THE LINE AFTER THE CALL IN THE FUNCTION GET USED IF THE FUNCTION KEEPS CALLING ITSELF??? Basically how does anything get printed if the function continuously callss itself.

Someone told me that the call goes forward until the != 0 is false, then the function 'unwinds' and that is when it calls itself in reverse and the putchar function is then acted upon.
Is this true????? I don't get that. Please explain.

#include <stdio.h>

void func(int n);

main()
{
   int q=0;
   printf("Enter a number:  ");
   scanf("%d",q);

   func(q);
}

void func(int n)

{
    if (n != 0)   {
      func(n / 2);
      putchar ('0' + n % 2);
    }
}

[doubleanti]

then the function 'unwinds' and that is when it calls itself in reverse

that would be correct... you can make even more complicated nesting setups if you'd need to... but i believe there is a limit to the recursive nesting you can do... what don't you 'get' about it?