#define versus const

[johny smith]

I have never really understood the difference between

1.) #define NUMBER 1.653

vs.

2.) const double NUMBER = 1.653

I know that the #define is taken care of by the pre-processor and the
compiler is used in the second case but why would one be chosen over the
other.

One book I read suggested that your should prefer the compiler to the
preprocessor, but why does it really matter?

Thanks in advance.

 

[Gregg]

I have never really understood the difference between

1.) #define NUMBER 1.653

vs.

2.) const double NUMBER = 1.653

I know that the #define is taken care of by the pre-processor and the
compiler is used in the second case but why would one be chosen over the
other.

One book I read suggested that your should prefer the compiler to the
preprocessor, but why does it really matter?

Thanks in advance.

One reason is that you will typically get more meaningful diagnostics if
you misuse the symbol.

But a more important reason is that, unlike #define, a const symbol obeys
scoping rules, so it won't have the potential for nasty side-effects,
substituting itself where it doesn't belong.

Gregg

 

[Heinz Ozwirk]

I have never really understood the difference between

1.) #define NUMBER 1.653

vs.

2.) const double NUMBER = 1.653

I know that the #define is taken care of by the pre-processor and the
compiler is used in the second case but why would one be chosen over the
other.

One book I read suggested that your should prefer the compiler to the
preprocessor, but why does it really matter?

One reason, among many others:

const int NUMBER = -42;
int main()
{
int x = -NUMBER;
}

Now replace the const by a #define and let a novice try to understand the compiler's message.

Heinz

 

[Unforgiven]

I have never really understood the difference between

1.) #define NUMBER 1.653

vs.

2.) const double NUMBER = 1.653

I know that the #define is taken care of by the pre-processor and the
compiler is used in the second case but why would one be chosen over
the other.

One book I read suggested that your should prefer the compiler to the
preprocessor, but why does it really matter?

For one thing #define is not typesafe, while const is.

Another thing to keep in mind is that #define is text substitution, not a
variable.
That means that if you do this:
#define NUMBER 5+2;

int x = 3 * NUMBER;

The value of x is now 17, while with a const it would've been 21.

 

[John Carson]

One reason, among many others:

const int NUMBER = -42;
int main()
{
int x = -NUMBER;
}

Now replace the const by a #define and let a novice try to understand
the compiler's message.

Heinz

I assume that you expect that it will expand to

int x = --42;

and hence an error. Interestingly enough, neither VC++ 7.1 (which assigns 42
to x) nor Comeau online give errors.

 

[Petec]

Unforgiven wrote:

#define NUMBER 5+2;

int x = 3 * NUMBER;

The value of x is now 17, while with a const it would've been 21.

And with a semicolon on the end of your #define, if you do this:
int x = NUMBER * 3;

You will get a compile error.

- Pete

 

[RM]

int x = --42;

What's wrong with this? It seems perfectly legal to me.
I would expect any compiler to perform double negation.

 

[JKop]

Unforgiven posted:

#define NUMBER 5+2;

If you have #define statements like that then enclose them in brackets.


#define NUMBER (5+2)

 

[Julie]

Unforgiven posted:


If you have #define statements like that then enclose them in brackets.

#define NUMBER (5+2)

You mean enclose them in parentheses.

<nitpick>

( is a parenthesis, plural parentheses

[ is a bracket

{ is a brace

< is an angle bracket

</nitpick>

 

[John Carson]

What's wrong with this? It seems perfectly legal to me.
I would expect any compiler to perform double negation.

-- is interpreted as the prefix decrement operator, not as a double minus.
You cannot apply the decrement operator to a constant (it must be a
modifiable lvalue).

To get double negation, you need a space between the two minus signs.

 

[Paul Mensonides]

-- is interpreted as the prefix decrement operator, not as a double minus.
You cannot apply the decrement operator to a constant (it must be a
modifiable lvalue).

To get double negation, you need a space between the two minus signs.

The preprocessor operates on preprocessing tokens, not text. The "splicing"
that you appears above happens after tokenization. This results in two adjacent
minus tokens (-) with no intervening whitespace. It is absolutely not a
pre-decrement operator.

Regards,
Paul Mensonides

 

[Duane Hebert]

Unforgiven posted:


If you have #define statements like that then enclose them in brackets.

#define NUMBER (5+2)

You mean enclose them in parentheses.

<nitpick>

( is a parenthesis, plural parentheses

[ is a bracket

{ is a brace

< is an angle bracket

</nitpick>

Unless of course you're not in the states.
In Canada for example.

 

[John Carson]

The preprocessor operates on preprocessing tokens, not text. The
"splicing" that you appears above happens after tokenization. This
results in two adjacent minus tokens (-) with no intervening
whitespace. It is absolutely not a pre-decrement operator.

Regards,
Paul Mensonides

I was referring to

int x = --42;

in the source code. Such source code will not compile because -- is
interpreted as the prefix decrement operator.

 

[John Carson]

Unforgiven posted:

#define NUMBER 5+2;

If you have #define statements like that then enclose them in
brackets.

#define NUMBER (5+2)

You mean enclose them in parentheses.

<nitpick>

( is a parenthesis, plural parentheses

[ is a bracket

{ is a brace

< is an angle bracket

</nitpick>

Unless of course you're not in the states.
In Canada for example.

I tend to call ( and ) round brackets. The Oxford dictionary agrees that
this is a correct usage. However, the C++ standard takes a different view
and I think it is the relevant authority in this case. It consistently uses
the word "parentheses".

 

[Paul Mensonides]

I was referring to

int x = --42;

in the source code. Such source code will not compile because -- is
interpreted as the prefix decrement operator.

Okay, my apologies.

Regards,
Paul Mensonides

 

[JKop]

Julie posted:

Unforgiven posted:


If you have #define statements like that then enclose them in brackets.

#define NUMBER (5+2)

You mean enclose them in parentheses.

<nitpick>

( is a parenthesis, plural parentheses

[ is a bracket

{ is a brace

< is an angle bracket

</nitpick>

I'm in Ireland, (and we call them brackets).


-JKop

 

[Luther Baker]

I'm in Ireland, (and we call them brackets).

Hi JKop,

Curious, what do you call the squared *thingies* in Ireland?

[ ]

-Luther

 

[JKop]

Luther Baker posted:

I'm in Ireland, (and we call them brackets).

Hi JKop,

Curious, what do you call the squared *thingies* in Ireland?

[ ]

-Luther

( ) Brackets

[ ] Square brackets / Block brackets

{ } Chain brackets


Sin a nglaonn muid orthu in Éirinn!


-JKop

 

[JKop]

JKop posted:

Luther Baker posted:

I'm in Ireland, (and we call them brackets).

Hi JKop,

Curious, what do you call the squared *thingies* in Ireland?

[ ]

-Luther

( ) Brackets

[ ] Square brackets / Block brackets

{ } Chain brackets


Sin a nglaonn muid orthu in Éirinn!


-JKop

As for:

< >


They're not used very much. We'd probably called them Arrow brackets or V
brackets.


-JKop

 

[Duane]

I tend to call ( and ) round brackets. The Oxford dictionary agrees that
this is a correct usage. However, the C++ standard takes a different view
and I think it is the relevant authority in this case. It consistently uses
the word "parentheses".

Except for where it refers to expressions being "bracketed" <g>

It's funny in Quebec, in French it's basically the same as in English
(parentheses etc.) but in English, parenthesis are brackets and
brackets are square brackets and braces are curly brackets.