increment evaluation

[pradeeparc]

hii,
plz help to knw how this prg wrk in detail


#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

 

[user923005]

hii,
plz help to knw how this prg wrk in detail

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

That is an example of undefined behavior (for several reasons).
You have a varadic function (printf) with no protype in scope.
You have a function macro which is given an argument used more than
once which is incremented causing several updates with no intervening
sequence point.

Probably, you want something like this:

#include <stdio.h>

static long CUBE (const long x)
{
printf("%d * %d * %d ", x, x, x);
return (x * x * x);
}

int main (void)
{
long a;
int b = 3;
a = CUBE(b++);
printf (" = %ld\n", a);

a = CUBE(b);
printf (" = %ld\n", a);

return 0;
}

 

[Richard Heathfield]

(e-mail address removed) said:

hii,
plz help to knw how this prg wrk in detail

It doesn't.

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);

See the FAQ: http://c-faq.com/cpp/safemacros.html

 

[Joachim Schmitz]

hii,
plz help to knw how this prg wrk in detail

This style of writing isn't received well here... this is a news group and
not a chat room

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

It invokes Undefined Behavoir because
a) you don't provide a prototype for a varadic funtion, printf() e.g. by
#include <stdio.h>
b) the output you intend to generate doesn't end with a linefeed ('\n'), so
your program may or may not produce any output
c) the macro CUBE has side effects that modify an operator several times
without a sequence point.

I guess your real question is about the macro CUBE
That macro is expanded by the preprocesser, so your compiler actually sees:

a=(b++*b++*b++);

When b gets incremented is up to the implementation as long as it happens
before the next sequence point.
On implementation I tried this on came up with "606" (i.e a=60 or 3*4*5 and
b=6), another with "276" (i.e. a=27 or 3*3*3 and b=6) and both are right.

Also you shouldn't use main() but rather int main(void) and also end it with
a return 0; (or EXIT_SUCCESS or EXIT_FAILURE from <stdlib.h>)

Bye, Jojo

 

[Martin Ambuhl]

hii,
plz help to knw how this prg wrk in detail

Given that you are so sloppy with your writing that "hii", "plz", "knw",
"prg", and "wrk" are all childish gibberish, it is unlikely that you
have enough respect for a language to ever be a competent programmer.

Of course, your program doesn't work at all, so it makes no sense to
explain in detail how it works. It has undefined behavior.

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

We start by rewriting it into C, but preserving your undefined behavior.

#include <stdio.h> /* added header for declaration of
variadic function printf */
#define CUBE(x) (x*x*x)
int main(void)
{ /* added return type */
int a, b = 3;
a = CUBE(b++); /* undefined operation on b, see
expansion below. */
printf("%d%d\n", a, b); /* added end of line character */
return 0; /* added return of value from function
returning a value */
}

On macro substitution, this expands to:

#include <stdio.h> /* added header for declaration of
variadic function printf */
int main(void)
{ /* added return type */
int a, b = 3;
a = (b++ * b++ * b++); /* undefined operation on b

[this is the expansion] */
printf("%d%d\n", a, b); /* added end of line character */
return 0; /* added return of value from function
returning a value */
}

The assignment statement is yet another boring example of the same old
undefined behavior that gets posted every September (and September never
ends). Please check the FAQ <http://c-faq.com/index.html> for the
explanation. You ought to have done this before (and instead of(
posting. Check the first the questions under "Expressions" (3.1-3.3).
But please try reading the whole thing.

 

[Martien Verbruggen]

hii,
plz help to knw how this prg wrk in detail

Please, in the future, make an attempt to spell correctly. The little
bit of effort you save in typing, if any, means all your readers have to
work a little bit harder to parse your message. It doesn't look cool
either. It looks silly.

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

This program invokes undefined behaviour, for several reasons. Please
see the C FAQ at c-faq.com, for example, and read questions 3.2, 10.1,
11.35, 15.21, and then read the whole thing. It's really worth the time.

Martien

 

[Chris Dollin]

hii,
plz help to knw how this prg wrk in detail

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

Tht prg ds nt wrk t ll; t hs t lst tw xmpls f "ndfnd bhvr". Y ddn't #ncld
<std.h> s th cll t prntf sn't dfnd. ls, th xprssn `CUB(b++)` xpnds t
`b++ * b++ * b++`, whch vlts /rqrmnt/ tht n xprssn wrts t mst nc t
vrbl btn sqnc pnts; fr dtls s th FQ.

 

[Philip Potter]

hii,
plz help to knw how this prg wrk in detail


#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);
}

Others have said that this program causes undefined behaviour. What does
this mean? It means Bad Things.

The C programming language is defined by a set of standards published by
ISO. The main ones are C89 (the first one), and C99 (the most recent).
The standard describes what a valid C compiler (or to use the Standard's
language, "implementation") must do. In certain places, the standard
gives the implementation a range of options - e.g. int can be any size,
as long as it's 16 bits or more.

For a program which causes undefined behaviour (UB), the standard places
no restrictions on the implementation. This means that the
implementation can do *anything it likes* when it encounters UB. What
this means is that a compiler which is in every way a working and
correct C compiler can fail to compile your code - or worse, compile
your code into something with bugs in it. Given there are hundreds (if
not thousands) of C implementations out there, this is a Bad Thing.

Of course, you may find that *your* compiler works exactly as you expect
it to. This is allowed by the Standard, because it places no
restrictions on the compiler. But one of the reasons for writing in C is
that there are many different C compilers on many different types of
computer, and if you do not invoke UB then the Standard guarantees your
program will work on *all* of these compilers without needing a rewrite.
This is called "portability". If you rely on quirks of your own
compiler, it may not compile on any other.

Why would you want to write code that will compile on any C compiler?
Well, it might be nice if you could give (or sell!) your nice Windows
program to Linux users at no extra cost to yourself. Another reason is
that if you write C code that works on lots of C compilers, then users
of all those compilers will know what you mean and will be able to help.
If you write C code which only works on your compiler, then you cut
yourself off from that expertise, because users of other compilers are
not familiar with the quirks of your compiler.

There are sometimes good reasons for writing code for which the Standard
does not define correct behaviour. This includes using system-specific
features such as graphics, networks, when standard C code to achieve
what you want doesn't exist. However in this situation standard C code
to do what you want *does* exist, so you should write standard C.

 

[Richard]

Given that you are so sloppy with your writing that "hii", "plz",
"knw", "prg", and "wrk" are all childish gibberish, it is unlikely
that you have enough respect for a language to ever be a competent
programmer.

Of course, your program doesn't work at all, so it makes no sense to
explain in detail how it works. It has undefined behavior.

What IS wrong with you people? You *know* others have already pointed
this out.

 

[karthikbalaguru]

hii,
plz help to knw how this prg wrk in detail

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);



}- Hide quoted text -

- Show quoted text -

Be alert - Some books have solutions for this and it is a
famous question in few C tests. But , in reality this cannot
have a defined solution.

Ans - Undefined Behaviour.

The Macro CUBE has side effects that modify an operator several times
without a sequence point.

Refer C-Faq and Kernighan & Ritchie books for the correct
answer.

Karthik Balaguru

 

[John Bode]

hii,
plz help to knw how this prg wrk in detail

#define CUBE(x) (x*x*x)
main()
{
int a,b=3;
a=CUBE(b++);
printf("%d%d",a,b);

}

Others have pointed out that CUBE(b++) evaluates to (b++*b++*b++),
which invokes undefined behavior (IOW, the compiler is under no
obligation to generate a correct or meaningful result).

This is a point against using macros as inline functions; they can
introduce a point of failure in your code (or at least a point of
undefined behavior, which in many cases amounts to the same thing).
Better to use the standard library function pow() for this kind of
thing:

#include <stdio.h>
#include <math.h>

int main(void)
{
int a, b = 3;

a = (int) pow((double) b++, 3.0);
printf ("a=%d, b=%d\n", a,b);
return 0;
}

Depending on your platform, you may have to explicitly link in the
math library (e.g., on my linux system, I have to use the "-lm"
argument with gcc in order to get the math library code).

 

[Chris Dollin]

Be alert - Some books have solutions for this and it is a
famous question in few C tests. But , in reality this cannot
have a defined solution.

Ans - Undefined Behaviour.

The Macro CUBE has side effects that modify an operator
variable.

several times without a sequence point.

Refer C-Faq and Kernighan & Ritchie books for the correct
answer.

 

[Mark L Pappin]

karthikbalaguru wrote:

The macro 'CUBE()' has no side effects.
The expression 'b++' has a side effect.

Using an expression with a side effect as an argument to a macro is a
Bad Idea if that macro evaluates that argument more than once.

The macro 'CUBE()' evaluates its argument more than once.

mlp

 

[Charlie Gordon]

The macro 'CUBE()' has no side effects.
The expression 'b++' has a side effect.

Using an expression with a side effect as an argument to a macro is a
Bad Idea if that macro evaluates that argument more than once.

The macro 'CUBE()' evaluates its argument more than once.

Technically, the macro does not "evaluate" its arguments, it just expands to
a sequence of tokens that may be part of an expression where multiple
occurrences of a side effect invokes undefined behaviour.

int a = CUBE(b++); // invokes undefined behaviour;
size_t size = sizeof(CUBE(b++)); // far fetched, but OK.

Even the fact that the same argument be present more than once in the macro
expansion is not necessarily an issue:

#define NP(x,y) ((y) > 0) ? ((x) + 1) : ((x) - 1))

int a = NP(b++, 1); // side effect only evaluated once.

In the OPs macro, we have more than one misunderstanding on how macros
operate: the macro argument is expanded 3 times in such a way as to cause
undefined behaviour for most side effects *and* it is not properly
parenthesized in the expansion, causing it to not evaluate as expected:

CUBE(a+1) -> a+1*a+1*a+1 -> 3 * a + 1

You can fix this by always surrounding macro arguments with pairs of
parentheses in the definition:

#define CUBE(x) ((x)*(x)*(x))

but is will not prevent the issue related to side effects.

Macros are *very* difficult to master, newbies should avoid them. The OP
can accomplish the same effect safely and correctly with an inline function:

static inline int cube(int x) { return x * x * x; }

 

[user923005]

Macros are *very* difficult to master, newbies should avoid them. The OP
can accomplish the same effect safely and correctly with an inline function:

static inline int cube(int x) { return x * x * x; }

Note:
'inline' keyword requires C99

There are several C90 compilers that support it as an extension, but
it is not required by the langauge.

Probably, you already know that but I am not sure if the OP does.

 

[Charlie Gordon]

Note:
'inline' keyword requires C99

There are several C90 compilers that support it as an extension, but
it is not required by the langauge.

Probably, you already know that but I am not sure if the OP does.

The OP should understand that it is easier to find a compiler that supports
inline functions for any desktop PC than to master the art of C macros ;-)