#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]

"johny smith" <pr**************@charter.net> wrote in
news:10*************@corp.supernews.com:

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]

"johny smith" <pr**************@charter.net> schrieb im Newsbeitrag news:10*************@corp.supernews.com...

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]

johny smith wrote:

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.

--
Unforgiven

[John Carson]

"Heinz Ozwirk" <wa******@gmx.de> wrote in message
news:c9*************@news.t-online.com

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.
--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[Petec]

Unforgiven wrote:
<snip>

#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]

JKop wrote:

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>

[John Carson]

"RM" <I_am_not_@_home.com> wrote in message
news:XM2uc.582962$Pk3.139545@pd7tw1no

int x = --42;

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.
--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[John Carson]

"Paul Mensonides" <le******@comcast.net> wrote in message
news:1-********************@comcast.com

"John Carson" <do***********@datafast.net.au> wrote in message
news:40********@usenet.per.paradox.net.au...

"RM" <I_am_not_@_home.com> wrote in message
news:XM2uc.582962$Pk3.139545@pd7tw1no

int x = --42;
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.

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
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[John Carson]

"Duane Hebert" <sp**@flarn2.com> wrote in message
news:IC**********************@wagner.videotron.net

"Julie" <ju***@nospam.com> wrote in message
news:40***************@nospam.com...

JKop wrote:

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".
--
John Carson
1. To reply to email address, remove donald
2. Don't reply to email address (post here instead)

[Paul Mensonides]

"John Carson" <do***********@datafast.net.au> wrote in message
news:40******@usenet.per.paradox.net.au...

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:

JKop wrote:

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>

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

[Luther Baker]

JKop wrote:

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:

JKop wrote:

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:

JKop wrote:

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]

"John Carson" <do***********@datafast.net.au> wrote in message
news:40********@usenet.per.paradox.net.au...

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.

[Mike Smith]

johny smith wrote:

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?

Here's another reason in addition to those already given:

#define MACRO 1.653

const double CONST = 1.653;

double Square(double const *p)
{
return (*p) * (*p);
}

int main()
{
double a = Square(&MACRO); // won't compile

double b = Square(&CONST); // compiles OK

return 0;
}

--
Mike Smith

[Tim Slattery]

Mike Smith <mi*******************@acm.DOT.org> wrote:

johny smith wrote:

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?
Here's another reason in addition to those already given:

#define MACRO 1.653

const double CONST = 1.653;

double Square(double const *p)
{
return (*p) * (*p);
}

int main()
{
double a = Square(&MACRO); // won't compile

Certainly not! After the preprocessor finishes with this line it look
like this:

double a = Square(&1.653);

which is meaningless.

double b = Square(&CONST); // compiles OK
CONST is a variable, not a macro, so the preprocessor does nothing to
this line.
return 0;
}

--
Tim Slattery
Sl********@bls.gov

[Karl Heinz Buchegger]

Tim Slattery wrote:

Here's another reason in addition to those already given:

#define MACRO 1.653

const double CONST = 1.653;

double Square(double const *p)
{
return (*p) * (*p);
}

int main()
{
double a = Square(&MACRO); // won't compile
Certainly not! After the preprocessor finishes with this line it look
like this:

double a = Square(&1.653);

which is meaningless.

Didn't the comment in this line say: won't compile ?

double b = Square(&CONST); // compiles OK

CONST is a variable, not a macro, so the preprocessor does nothing to
this line.

And that's why Mike marked this line as : compiles OK
--
Karl Heinz Buchegger
kb******@gascad.at

[Dave Moore]

JKop <NU**@NULL.NULL> wrote in message news:<GK***************@news.indigo.ie>...

JKop posted:

Luther Baker posted:

JKop wrote:

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.

How about angle brackets? <g>

Dave Moore

[Mike Smith]

Karl Heinz Buchegger wrote:

Tim Slattery wrote:

Here's another reason in addition to those already given:

#define MACRO 1.653

const double CONST = 1.653;

double Square(double const *p)
{
return (*p) * (*p);
}

int main()
{
double a = Square(&MACRO); // won't compile

Certainly not! After the preprocessor finishes with this line it look
like this:

double a = Square(&1.653);

which is meaningless.

Didn't the comment in this line say: won't compile ?

double b = Square(&CONST); // compiles OK

CONST is a variable, not a macro, so the preprocessor does nothing to
this line.

And that's why Mike marked this line as : compiles OK

I suppose I should simply have said that a const object is an object,
and can be treated like one, whereas a literal substitution cannot. <sigh>

--
Mike Smith