quick #define question

If you do that God will strike you down.

yes noob, you are correct

quote:

---

Original post by n0ob
#define A 10
#define B 200 / A

B should be replaced by the constant 20, right? Just trying to make sure..

Kings of Chaos

---

No, B would be equivalent to typing "200 / 10". Which could lead to some problems. For instance, char str[ B ]; wouldn't compile, since B isn't a constant. B++ would probably break as well.

In short, defines can be tricky to use; I tend to avoid them, since they often have unexpected side effects (one exception being the standard #ifndef/#define/#endif trick for making header files get parsed once).

-Odd the Hermit

EDIT: Stupid thing HTML-ized my array.

[edited by - Odd the Hermit on August 28, 2003 12:12:34 PM]

Let me clarify Raloth''s reply a bit.

Yes, that is the general idea. But you have violated several major things which make #defines evil:

- Defining a simple letter is a bad idea. Why? Say I have a function called DoAThing. When the preprocessor comes around, it sees that A and replaces it with your number. So you would be trying to call Do10Thing, which would seem to result in a very odd error.

- Use parenthesis like crazy when using #defines, as they don''t follow order of operations. Say you had this:

#define B A + 10

And you had the expression A * 10 somehwere in code. You would expect that to be (A + 10) * 10, but it wouldn''t. The preprocessor does things directly, so it would go out to A + 10 * 10, or A + 100.

This is why #defines are evil - use C++ constants, as they give you more flexibility and don''t let you shoot yourself in the foot like this.

Thank you for your prompt replies.. although they slightly conflict eachother. I used simple letters so as not to confused some of you.

You actually could char str[ B ]; Even if you did char str[ 200 / 10]; it still works. At least on my compiler.

I'm not exactly sure about #defines being replaced as part of a word.. (why NOT to use a simple letter..) If you had:

#define foo "Test"
int foobar = 10;
int bob = foobar;

It all works fine on my compiler.. What you were saying would lead to code looking like:
int "Test"bar = 10;
int bob = "Test"bar;
Which I don't think would work.

I will, however, believe what you said about using parentheses.

Kings of Chaos

[edited by - n0ob on August 28, 2003 3:51:14 PM]

#defines aren''t evil, just prone to bugs IF you don''t know what you''re doing or are sloppy. #defines can be your best friend if you use them properly, which for some reason, alot of people don''t seem to know how to do. But just cuz something is complicated doesn''t make it evil. C++ in general is complicated, but is is the shining light of goodness!

When you do have to use #defines that result in a mathematical expresion, it''s good practice to place them in in parentheses, for example:

#define A 300
#define B 200 + A // this may work

#define C (200 + A)// but this is better

Here''s why:

cout << B * 10; // should be 5000, but its really 3200

cout << C * 10; // results in 5000, because your intended order of operation was preserved.

Of coarse, that may NOT be your desired order of operation, but you get the point. These types of bugs are often difficult to find and is one of the main reasons people avoid #defines.

Ravyne, NYN Interactive Entertainment
[My Site][My School][My Group]

quote:

---

Original post by UberGeek
- Defining a simple letter is a bad idea. Why? Say I have a function called DoAThing. When the preprocessor comes around, it sees that A and replaces it with your number. So you would be trying to call Do10Thing, which would seem to result in a very odd error.

---

quote:

---

Original post by Anonymous Poster
If you were any more wrong, the world would explode.

---

To explain the issue rather than berate, the DoAThing example is wrong because macros have a different namespace than functions.

For details consult: C Reserved Identifiers - there''s also a C++ page there - or at least there used to be. I''m not able to pull the site up. Here''s the google cache: C Reserved Identifiers. The information regarding namespaces is found in the section titled "Second Surprise: They Look the Same, But They''re Different"

the DoAThing example is wrong, because both MACROS and FUNCTIONS and EVERYTHING ... only matches WHOLE TOKENS ...

so the preprocessor WOULD replace a function named A(), but not MyA() ... cause the token is "MyA" ...

quote:

---

Original post by LessBread
To explain the issue rather than berate, the DoAThing example is wrong because macros have a different namespace than functions.

---

Can you elaborate a bit? The reason the ''A'' in DoAThing won''t be replaced is because defines only replace whole tokens, not everything they find...but I''m still curious what it is you are talking about...

quote:

---

Original post by Promit
Can you elaborate a bit? The reason the ''A'' in DoAThing won''t be replaced is because defines only replace whole tokens, not everything they find...but I''m still curious what it is you are talking about...

---

I don''t remember what I was thinking when I wrote that. The answer is that macros only replace whole tokens. The link I provided is still worth knowing about just the same.