#include <iostream>
using namespace std;
#define BAND(x) (((x)>5 && (x)<10) ? (x) : 0) //LOOK AT THIS LINE
int main() {
for(int i = 4; i < 11; i++) {
int a = i;
cout << "a = " << a << endl << '\t';
cout << "BAND(++a)=" << BAND(++a) << endl;
cout << "\t a = " << a << endl;
}
return 0;
}
IN COMPARISON TO
#include <iostream>
using namespace std;
inline band(int x) {return (x>5 && x<10)? x : 0;} //THIS LINE
int main() {
for(int i = 4; i < 11; i++) {
int a = i;
cout << "a = " << a << endl << '\t';
cout << "band(++a)=" << band(++a) << endl;
cout << "\t a = " << a << endl;
}
return 0;
}
c++ inconsistency...really, look inside.
Author
Why doesnt the macro equivilent of the Inline function act the same, the code is a replica. However, strange enough i get diff results. Here look.
The wrong thing about macros is, that they are only textual replacements.
In you case the line
is replaced by
In you case the line
cout << "BAND(++a)=" << BAND(++a) << endl;is replaced by
cout << "BAND(++a)=" << (((++x)>5 && (++x)<10) ? (++x) : 0) << endl;
If you haven't done so already, take a look at the C++ FAQ Lite specifically this section: Why should I use inline functions instead of plain old #define macros?
Author
oh lol, so its something that was around, i thought this discovery would make me famous like the pioneers..nah just playin, thanks for that though...
I'm pretty sure that the behaviour with the macro version isn't even (pardon the pun) defined.
Quote:Original post by Zahlman
I'm pretty sure that the behaviour with the macro version isn't even (pardon the pun) defined.
Invoking the macro on its own with ++a is well defined -- logical operations and the ternary operation imply sequence points and have a well defined order.
Quote:Original post by Polymorphic OOPQuote:Original post by Zahlman
I'm pretty sure that the behaviour with the macro version isn't even (pardon the pun) defined.
Invoking the macro on its own with ++a is well defined -- logical operations and the ternary operation imply sequence points and have a well defined order.
Can you go into more detail? I never understood what would be defined behavior in cases like these and not.
C++ has the concept of sequence points. A sequence point is basically a point in the code where everything before it has to have finished evaluating before execution proceeds any further. For example: the end of a statement is a sequence point. So this is well defined:
++a;
++a;
Even though this is not:
++a + ++a;
Another example is a function call: all arguments to the function call must be evaluated before the function is actually called. So if you have foo(++a, ++b), you know that both ++a and ++b were both evaluated before foo() was called.
Logical and and or, the ternary operator and the comma operator also have a sequence point after the first expression. So in A && B, A || B, A , B and A ? B : C the A has to finish evaluating, with all its side effects before B (or C) is evaluated. So ++a && ++a has well defined behaviour even though ++a + ++a</t> doesn't.
++a;
++a;
Even though this is not:
++a + ++a;
Another example is a function call: all arguments to the function call must be evaluated before the function is actually called. So if you have foo(++a, ++b), you know that both ++a and ++b were both evaluated before foo() was called.
Logical and and or, the ternary operator and the comma operator also have a sequence point after the first expression. So in A && B, A || B, A , B and A ? B : C the A has to finish evaluating, with all its side effects before B (or C) is evaluated. So ++a && ++a has well defined behaviour even though ++a + ++a</t> doesn't.
Quote:Original post by SiCrane
Another example is a function call: all arguments to the function call must be evaluated before the function is actually called. So if you have foo(++a, ++b), you know that both ++a and ++b were both evaluated before foo() was called.
Just to add one more: while you can be sure that they will be evaluated before the function call, you can't be sure about the order. So doing something like foo(a,++a) and relying on a left to right order isn't a good idea (and real fun to debug when differently optimized builds or builds from different compilers behave differently).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
