Question about macros

Hi, I have a question about macros. I am developing a cpp program that will be run as a standalone exe. The exe will run with a parameter inverse=true or false.

Code:

---

test.exe -inverse=true OR test.exe -inverse=false.

---

I wish to define 2 macros prefix and suffix such as their values should depend on the command line parameter inverse.

When inverse is true,

Code:

---

#define PREFIX "P5F"
#define SUFFIX "P5J"

---

Whereas, when inverse is false,

Code:

---

#define PREFIX "P5J"
#define SUFFIX "P5F"

---

How can I achieve this? Is there a way I can define a macro so that the value of PREFIX and SUFFIX are set depending on the value of parameter "inverse".

Thanks

Nope. Macros are fixed at compile time. They can't be made to depend on a runtime value.

Thanks for your reply brewbuck. So a better appraoch would be to use a const char pointer in my code instead of a macro?

Something like

Code:

---

const char* prefix = NULL;
const char* suffix=NULL;

if(inverse==true)
{
    prefix = "P5F";
    suffix = "P5J";
}
else
{
    prefix = "P5J";
    suffix = "P5F";
}

---

Is this a good way?

Indeed.

I personally wouldn't do "if (inverse == true)", but do "if (inverse)".

--
Mats

Quote:

---

Originally Posted by matsp

Indeed.

I personally wouldn't do "if (inverse == true)", but do "if (inverse)".

--
Mats

---

I always do if ( something == true ) or if ( ptr != NULL ) because it's more explicit and easier to read if you're skimming through the code quickly; and it was one of the coding standards at my first company.

Doesn't it just increase the risk of

Code:

---

if (something = true)

---

?

Quote:

---

Originally Posted by anon

Doesn't it just increase the risk of

Code:

---

if (something = true)

---

?

---

I've seen people write it backwards to prevent this error.

if(constant = something)

This will always yield an error.

Quote:

---

Originally Posted by Desolation

This will always yield an error.

---

Yes, assuming that the left hand expression is an rvalue or const. However, because this does not map to the usual way one would say it, I would argue that this would then make it harder "to read if you're skimming through the code quickly".

Basically, I see no advantage to comparing to a boolean literal. If the variable is not a bool, and you want to be explicit about it, then compare with an appropriate value (e.g., zero), or call an appropriate named function (e.g., use the fail() member function of an input stream instead of relying on an implicit conversion). In that sense, I see some value with comparing a pointer with a null pointer constant.

Quote:

---

Originally Posted by anon

Doesn't it just increase the risk of

Code:

---

if (something = true)

---

?

---

Yes, but any decent compiler should give you a warning when you do this.

Quote:

---

Originally Posted by cpjust

I always do [B]if ( something == true )

---

Well, then shouldn't you be doing:

Code:

---

if( ( something == true ) == true )

---

And if you're going to do that, might as well:

Code:

---

if( ( ( something == true ) == true ) == true )

---

etc...

Quote:

---

Originally Posted by brewbuck

Well, then shouldn't you be doing:

Code:

---

if( ( something == true ) == true )

---

And if you're going to do that, might as well:

Code:

---

if( ( ( something == true ) == true ) == true )

---

etc...

---

That would make no sense. That's not being any more explicit, that's just being crazy.

But it is more explicit! It is! It is!

What about:

Code:

---

if ((something == false) == true)

---

Quote:

---

Originally Posted by cpjust

That would make no sense. That's not being any more explicit, that's just being crazy.

---

Just to clarify: under what situations did your first company's coding standard mandate the comparison with a boolean literal?

As I noted in post #8, I can understand the comparison with a null pointer constant to be explicit, and of course the use of a named function instead of an implicit conversion (directly or indirectly) to bool. But to compare a boolean flag or a boolean value returned by a function call with a boolean literal?

Quote:

---

Originally Posted by cpjust

That would make no sense. That's not being any more explicit, that's just being crazy.

---

Just to clarify: under what situations did your first company's coding standard mandate the comparison with a boolean literal?

As I noted in post #8, I can understand the comparison with a null pointer constant to be explicit, and of course the use of a named function instead of an implicit conversion (directly or indirectly) to bool. But to compare a boolean flag or a boolean value returned by a function call with a boolean literal?

Quote:

---

Originally Posted by laserlight

Yes, assuming that the left hand expression is an rvalue or const. However, because this does not map to the usual way one would say it, I would argue that this would then make it harder "to read if you're skimming through the code quickly".

Basically, I see no advantage to comparing to a boolean literal. If the variable is not a bool, and you want to be explicit about it, then compare with an appropriate value (e.g., zero), or call an appropriate named function (e.g., use the fail() member function of an input stream instead of relying on an implicit conversion). In that sense, I see some value with comparing a pointer with a null pointer constant.

---

I did not say I used this form. It feels backwards to me and I wouldn't use it. Just felt like mentioning the alternative.

Quote:

---

Originally Posted by laserlight

Yes, assuming that the left hand expression is an rvalue or const. However, because this does not map to the usual way one would say it, I would argue that this would then make it harder "to read if you're skimming through the code quickly".

---

To add to this (okay, so Desolation just pointed this out, some other fact I will point out)...
USE WARNINGS (and a proper compiler).
If you do something like:

Code:

---

if(something = NULL)

---

Many compilers generate warnings at pedantic level, requesting you to put the expression in parenthesises to indicate it was actually what you wanted.

Quote:

---

Originally Posted by EVOEx

To add to this (okay, so Desolation just pointed this out, some other fact I will point out)...
USE WARNINGS (and a proper compiler).
If you do something like:

Code:

---

if(something = NULL)

---

Many compilers generate warnings at pedantic level, requesting you to put the expression in parenthesises to indicate it was actually what you wanted.

---

Warning Level 4 is all you need on Visual Studio to give you this warning.

Quote:

---

Originally Posted by laserlight

Just to clarify: under what situations did your first company's coding standard mandate the comparison with a boolean literal?

---

In all cases.
I think it was mostly to prevent confusing code like:

Code:

---

if ( something != false )

---

where they wanted it to be this instead:

Code:

---

if ( something == true )

---

which I agree with completely.
And also for consistency.

They also required us to compile with the highest warning levels and to select the "Treat Warnings as Errors" option.

Quote:

---

Originally Posted by cpjust

In all cases.

---

hmm... but wouldn't that mean that in the case of a sentinel value, instead of writing:

Code:

---

bool is_valid = false;
// ...
if (is_valid)
// ...

---

you would have to write:

Code:

---

bool is_valid = false;
// ...
if (is_valid == true)
// ...

---

Quote:

---

Originally Posted by laserlight

hmm... but wouldn't that mean that in the case of a sentinel value, instead of writing:

Code:

---

bool is_valid = false;
// ...
if (is_valid)
// ...

---

you would have to write:

Code:

---

bool is_valid = false;
// ...
if (is_valid == true)
// ...

---

---

That's right.
I think it's a lot easier to see:

Code:

---

if ( blah == false )

---

than it is to see:

Code:

---

if ( !blah )

---

especially on a friday evening when you barely got any sleep all week... :)

Quote:

---

Originally Posted by cpjust

That's right.
I think it's a lot easier to see:

---

That seems like a little of a straw man since "blah" is a poor name. With a descriptive name, I find that having to parse the extra "== true" or "== false" is harder, "especially on a friday evening when you barely got any sleep all week..." :)
Compare "if the input is valid" and "if the input is not valid" with "if it is true that the input is valid" and "if it is false that the input is valid".