#define vs. const

[Robert]

Greetings everyone,

I was wondering if a const variable or object took up space. I know
that a #define'd macro doesn't, as it's basically just interpreted by
the compiler. If a const does take up space, is there any reason to
choose it over a #define'd constant?

-- Thank you

P.S. if it makes any difference, I ssh to a SunOs machine where I use
g++ as my compiler.

[Greg Comeau]

In article <Xn************ ********@216.77 .188.18>,
Robert <gr*****@REMOVE hotmail.com> wrote:

I was wondering if a const variable or object took up space.
It might, or it might not. Generally speaking, usually a scalar
integeral need not take up space if their address is not taken.
Hence, the classic situation of somehting such as:

const int buf = 99;

char a[buf];

int main()
{
return 0;
}

Here, buf can be used to obtain the constant expression necessary
for the array dimension, and at the same time, the compiler probably
won't both to allocate any runtime space for it since it isn't
otherwise used. It can get slippery though. And there are
cases where compilers normally wouldn't do it:

const double d = 1234.4321;
const int array[999]; // int, but probably still allocated.

Of course, all this is notwithstanding program optimizations
that are allowed to occur.
I know
that a #define'd macro doesn't, as it's basically just interpreted by
the compiler. If a const does take up space, is there any reason to
choose it over a #define'd constant?

Check out http://www.comeaucomputing.com/techtalk/#definevsconst
for a higher level response, and not intended to be narrowminded
since as usual decisions should be context driven.
--
Greg Comeau / Comeau C++ 4.3.3, for C++03 core language support
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[E. Robert Tisdale]

Robert wrote:

I was wondering if a const variable or object took up space.
You are probably confusing C with C++.
I know that a #define'd macro doesn't
as it's basically just interpreted by the compiler.
I don't think that you *know* any such thing.
cat f.cc #ifdef UH
#define constant 1024*1024
#else //UH
const int constant = 1024*1024;
#endif//UH

extern
void g(int);

void f(void) {
g(constant);
}
g++ -DUH -Wall -ansi -pedantic -O3 -S -o f.sold f.cc
g++ -Wall -ansi -pedantic -O3 -S -o f.snew f.cc
diff f.sold f.snew
My compiler emits *exactly* the same code
whether I use #define or const.
If a const does take up space,
is there any reason to choose it over a #define'd constant?

C preprocessor macro definitions are dangerous.
They don't respect local scope for example.

[JKop]

Robert posted:

Greetings everyone,

I was wondering if a const variable or object took up space. I know that a #define'd macro doesn't, as it's basically just interpreted by the compiler. If a const does take up space, is there any reason to choose it over a #define'd constant?

-- Thank you
P.S. if it makes any difference, I ssh to a SunOs machine where I use g++ as my compiler.

MACROS ARE EVIL

Don't use macros.

There's is absolutlely no need for them in C++.

Macro constants -> const global variables
Macro functions -> inline functions

If you use macros for any other reason, eg. to get some new
special syntax, then it's perverted.

Not only do macro "functions" not follow scoping rules, but
also when they're passed the likes of:

Func(++a, b+=6)

Then they may increment "a" more than once and add 6 to
"b" more than once too.

Also if you want a callback function out of a macro:

CallBack(Func)

Well, let's just say it doesn't work.

MACROS WILL DIE

-JKop

[Ivan Vecerina]

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

MACROS ARE EVIL

Don't use macros.

There's is absolutlely no need for them in C++.

Macro constants -> const global variables
Macro functions -> inline functions
I agree that macros are evil, and that in most of their
current uses, they are best replaced as you suggested.
However, I wouldn't go as far as to say that there are
absolutely no need for them.
Include guards are usually based on macros, right?
If you use macros for any other reason, eg. to get some new
special syntax, then it's perverted. .... MACROS WILL DIE

Someday they may well be replaced by a better/safer mechanism.
So far, many find that there are still many legitimate uses
for them, and even developed supporting libraries.
For advanced examples see:
http://www.boost.org/libs/preprocessor/doc/index.html

At the language level itself, I wouldn't bet that new
extensions to the C preprocessor (e.g. variadic arguments)
won't be adopted in the next C++ standard.
Regards,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[Ioannis Vranos]

JKop wrote:

MACROS ARE EVIL

Don't use macros.

There's is absolutlely no need for them in C++.
Actually there are some uses with no other alternatives like #ifndef's.
But in general, they should be avoided.

Macro constants -> const global variables
Macro functions -> inline functions

and templates.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Rolf Magnus]

JKop wrote:

Robert posted:

Greetings everyone,

I was wondering if a const variable or object took up space. I know

that a #define'd macro doesn't, as it's basically just

interpreted by

the compiler. If a const does take up space, is there any

reason to

choose it over a #define'd constant?

--

Thank you

P.S. if it makes any difference, I ssh to a SunOs machine

where I use

g++ as my compiler.

MACROS ARE EVIL

Don't use macros.

That won't help without giving a reason.
There's is absolutlely no need for them in C++.

Macro constants -> const global variables
#ifndef FOO_H_INCLUDED
#define FOO_H_INCLUDED

//foo.h contents

#endif
Macro functions -> inline functions
#define ASSERT(x) \
if (!(x)) \
std::cerr << "Assert failure in line " << __LINE__ << std::endl;
If you use macros for any other reason, eg. to get some new
special syntax, then it's perverted.
That's your opinion.
Not only do macro "functions" not follow scoping rules, but
also when they're passed the likes of:

Func(++a, b+=6)

Then they may increment "a" more than once and add 6 to
"b" more than once too.
Even further, that may introduce undefined behaviour, like in the infamous
example:

#define MIN(x, y) ((x) < (y) ? (x) : (y))

//...
int a = 3;
int b = 5;
int c = MIN(a++, b--);
Also if you want a callback function out of a macro:

CallBack(Func)

Well, let's just say it doesn't work.

Macros also don't support namespaces and cannot be made members of classes.
Further, they are not type safe.

[Chris Theis]

"JKop" <NU**@NULL.NULL > wrote in message
news:pK******** **********@news .indigo.ie...
[SNIP]

MACROS ARE EVIL

Don't use macros.

There's is absolutlely no need for them in C++.
Sit back and relax for a moment ;-) I totally agree that macros are evil but
the statement that there is absolutely no need for them in C++ is more than
arguable. There are a couple of situations that spring to my mind where they
come in very handy. Just think of include guards, or of some more nifty uses
like in compile time asserts with more informative error messages. I simply
don´t know how you´d achieve it without a macro.

template <bool x> struct StaticAssert {
StaticAssert(.. .);
};
template <> struct StaticAssert<fa lse>{};
#define COMPILE_ASSERT( Expr, Msg ) \
{ \
class ERROR_##Msg {}; \
(void)sizeof( StaticAssert<(E xpr) != 0>(( ERROR_##Msg())) ); \
}

Macro constants -> const global variables
Macro functions -> inline functions
Point taken and you´re absolutey right there.

If you use macros for any other reason, eg. to get some new
special syntax, then it's perverted.
[SNIP]
MACROS WILL DIE

Wait and see, probably they might be replaced by some safer mechanism.

Regards
Chris

[Ioannis Vranos]

Chris Theis wrote:

Sit back and relax for a moment ;-) I totally agree that macros are evil but
the statement that there is absolutely no need for them in C++ is more than
arguable. There are a couple of situations that spring to my mind where they
come in very handy. Just think of include guards,
In most compilers inclusion guards can be replaced with #pragma
directives. Like

#pragma once
or of some more nifty uses
like in compile time asserts with more informative error messages. I simply
don´t know how you´d achieve it without a macro.

template <bool x> struct StaticAssert {
StaticAssert(.. .);
};
template <> struct StaticAssert<fa lse>{};
#define COMPILE_ASSERT( Expr, Msg ) \
{ \
class ERROR_##Msg {}; \
(void)sizeof( StaticAssert<(E xpr) != 0>(( ERROR_##Msg())) ); \
}

With an array of pointers to functions or objects may be?

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Robert]

Thanks everyone for your replies. I've been searching around and saw
this article: http://www.embedded.com/story/OEG20011016S0116 . It
mentions something about const variables/objects receiving performance
penalties.