Well, for one it's extremely simple, compared to your method, and two, it's really fast since it's dosn't involve invoking a function, but it's just a sugestion after all, the op can choose whatever method he prefer, i was just pointing it out.
Does C++ have a squared operator?
Well, for one it's extremely simple, compared to your method, and two, it's really fast since it's dosn't involve invoking a function, but it's just a sugestion after all, the op can choose whatever method he prefer, i was just pointing it out.
Except that Cornstalks function will be inlined in any decent compiler. It also avoids a rather nasty trap that your macro has, which can result in hard to diagnose bugs and produce undefined behavior. I'll leave it up to you to figure out what the trap is...
Well, for one it's extremely simple, compared to your method, and two, it's really fast since it's dosn't involve invoking a function, but it's just a sugestion after all, the op can choose whatever method he prefer, i was just pointing it out.
There are no disadvantages to the templated constexpr function. In Clang it is inlined at all optimizations levels except for -O0, and if you want to you could use __attribute__((always_inline)) to force it to inline under all circumstances. If you think macros are "fast" and functions are slow, you are using the wrong mindset.
I would stick with L. Spiro's suggestion. If you're using simple multiplications, a (good) compiler internally tries to solve this with bit shifting which is a very fast way of altering numbers. Adding stuff to the stack for such a simple operation is a waste.
Except that Cornstalks function will be inlined in any decent compiler. It also avoids a rather nasty trap that your macro has, which can result in hard to diagnose bugs and produce undefined behavior. I'll leave it up to you to figure out what the trap is...
What's the trap?
I took it from a very good c++ book, not that i really care anyway lol. I don't mean to be rude, but it would be pretty dumb to not call this macro correctly.
The parentesis should be able to proctect from the bug you speak of, i believe. If not, then ill just shut my trap :)
Hint: POW2(IncrementSomeNumberAndReturnIt()) does... what?
???
I just compiled this and it worked just fine (Answer 9)
#include "stdio.h"
#define POW2(x) ((x)*(x))
int test()
{
return 3;
}
int main()
{
int x = POW2(test());
printf("%d\n", x);
return 0;
}
Cool story, now try this one:
#include <iostream>
#define POW2(x) ((x)*(x))
class Foobar {
public:
Foobar() : _a(5) { }
int a() {
return _a++;
}
private:
int _a;
};
int main() {
using namespace std;
Foobar f;
int x = POW2(f.a());
cout << x << endl;
}
I just compiled this and it worked just fine (Answer 9)
#include "stdio.h" #define POW2(x) ((x)*(x)) int test() { return 3; } int main() { int x = POW2(test()); printf("%d\n", x); return 0; }
What happens if you try:
#include "stdio.h"
#define POW2(x) ((x)*(x))
int main()
{
int y = 3;
int x = POW2(++y);
printf("%d\n", x);
return 0;
}[spoiler]http://codepad.org/tolVAt92[/spoiler]
L. Spiro
I just compiled this and it worked just fine (Answer 9)
#include "stdio.h" #define POW2(x) ((x)*(x)) int test() { return 3; } int main() { int x = POW2(test()); printf("%d\n", x); return 0; }What happens if you try:
#include "stdio.h" #define POW2(x) ((x)*(x)) int main() { int y = 3; int x = POW2(++y); printf("%d\n", x); return 0; }[spoiler]http://codepad.org/tolVAt92[/spoiler]
L. Spiro
Cool story, now try this one:
#include <iostream> #define POW2(x) ((x)*(x)) class Foobar { public: Foobar() : _a(5) { } int a() { return _a++; } private: int _a; }; int main() { using namespace std; Foobar f; int x = POW2(f.a()); cout << x << endl; }
Hint: POW2(IncrementSomeNumberAndReturnIt()) does... what?
Three prime examples of the problems of using macros in this manner. Note that Spiro's results in undefined behavior.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
