Declaring war on macros

[JKop]

const unsigned short int AmountHumanAdul tTeeth = 32;

inline unsigned short int AddFive(unsigne d short int Numbr)
{
return Numbr + 5;
}
USE THESE!!
I've heard a stupid argument before that:

#define AmountHumanAdul tTeeth 32
is better because it saves memory, ie. there's no variable declared which
takes up memory.

Enlightenment time:

Upon execution, the ENTIRE program is loaded into memory, all the code for
all of the functions, all of the numbers and strings littered throughout the
code, eg.:

cout << "Hello";
are all loaded into memory. Thus, somewhere in memory you will have "Hello".

Thus, concordantly and therefore, you most certainly _are_ taking up memory
by using a macro instead of a const global variable. Furthermore, you may
even use MORE memory with a macro; For example, if you have the number "5"
littered throughout your program, you're not necessarily guaranteed that all
of the "5"'s will be taken from the same place in memory! There may be a
unique "5" in memory for every single seperate time you use it. Const global
variables are superior in EVERY WAY, BAR NONE.

As for macro functions: Similarly, there is absolutley NO JUSTIFICATION for
their use. Inline functions are superior in every way, BAR NONE!

[Rolf Magnus]

JKop wrote:

const unsigned short int AmountHumanAdul tTeeth = 32;

inline unsigned short int AddFive(unsigne d short int Numbr)
{
return Numbr + 5;
}
USE THESE!!
I've heard a stupid argument before that:

#define AmountHumanAdul tTeeth 32
is better because it saves memory, ie. there's no variable declared
which takes up memory.

Enlightenment time:

Upon execution, the ENTIRE program is loaded into memory, all the code
for all of the functions, all of the numbers and strings littered
throughout the code, eg.:

cout << "Hello";
are all loaded into memory. Thus, somewhere in memory you will have
"Hello".

Thus, concordantly and therefore, you most certainly _are_ taking up
memory by using a macro instead of a const global variable.
Furthermore, you may even use MORE memory with a macro; For example,
if you have the number "5" littered throughout your program, you're
not necessarily guaranteed that all of the "5"'s will be taken from
the same place in memory! There may be a unique "5" in memory for
every single seperate time you use it.
Actually, they might not even be taken from memory at all, or let's
better say from data memory. If you have a variable, it resides in
memory somewhere, and the compiler might need to create an instruction
that loads it from there. On assembler level that means there is an
instruction that says something like "load the value from memory
address 0xdeadbeef". If it's a macro, the literal 5 is usually directly
included in the instruction on assembler level, so the assembler
instruction would say "load the value 0x00000005". As you can see, the
instructions can be (and often are) of the same size, but in the first
case, you additionally need a memory location to save the value to (in
my example at address 0xdeadbeef). However, a constant can be used
"inline", just like the macro, so any decent compiler can also directly
put the literal 5 into the assembler instruction unless you try to take
its address, in which case the compiler needs to put it into data
memory to ensure it actually has an address. Since constants have
internal linkage by default, it would mean that each translation unit
that needs the address of the constant would need to store its own copy
of it in memory.

Anyway, in most cases, it's just not worth thinking about whether your
program will need a few bytes more. There are lots of much more
important reasons to use constants instead of macros.
Const global variables are superior in EVERY WAY, BAR NONE.
Some would say "global variables are evil".
As for macro functions: Similarly, there is absolutley NO
JUSTIFICATION for their use. Inline functions are superior in every
way, BAR NONE!

Right.

--
How come Superman could stop bullets with his chest,
but always ducked when someone threw a gun at him?

[tom_usenet]

On Wed, 28 Apr 2004 09:29:28 GMT, JKop <NU**@NULL.NULL > wrote:

As for macro functions: Similarly, there is absolutley NO JUSTIFICATION for
their use. Inline functions are superior in every way, BAR NONE!

Rolf's commented on the rest of it, but I take slight issue with the
above. Inline functions are superior only when it is possible to write
an inline function to do what the macro was doing. In many cases it
isn't. (For an example of advanced usage of preprocessor macros, check
out the boost library at www.boost.org)

Tom
--
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

[Michiel Salters]

JKop <NU**@NULL.NULL > wrote in message news:<YP******* ***********@new s.indigo.ie>...

As for macro functions: Similarly, there is absolutley NO JUSTIFICATION for
their use. Inline functions are superior in every way, BAR NONE!

inline int BYTES_NEEDED_FO R_INTS ( int no_ints )
{
return no_ints * sizeof(int);
}
typedef char[ BYTES_NEEDED_FO R_INTS( 5 ) ] int5;

Does your compiler accept this?

Regards,
Michiel Salters

[Julie]

JKop wrote:
[snip stuff that I don't want to comment on]

As for macro functions: Similarly, there is absolutley NO JUSTIFICATION for
their use. Inline functions are superior in every way, BAR NONE!

Please describe how to implement the (standard library) offsetof macro in terms
of an inline function that is 'far superior' (or at least equally inferior!).

[Julie]

JKop wrote:

const unsigned short int AmountHumanAdul tTeeth = 32;

inline unsigned short int AddFive(unsigne d short int Numbr)
{
return Numbr + 5;
}

USE THESE!!

I've heard a stupid argument before that:

#define AmountHumanAdul tTeeth 32

is better because it saves memory, ie. there's no variable declared which
takes up memory.

Enlightenment time:

Upon execution, the ENTIRE program is loaded into memory, all the code for
all of the functions, all of the numbers and strings littered throughout the
code, eg.:

cout << "Hello";

are all loaded into memory. Thus, somewhere in memory you will have "Hello".

Thus, concordantly and therefore, you most certainly _are_ taking up memory
by using a macro instead of a const global variable. Furthermore, you may
even use MORE memory with a macro; For example, if you have the number "5"
littered throughout your program, you're not necessarily guaranteed that all
of the "5"'s will be taken from the same place in memory! There may be a
unique "5" in memory for every single seperate time you use it. Const global
variables are superior in EVERY WAY, BAR NONE.

As for macro functions: Similarly, there is absolutley NO JUSTIFICATION for
their use. Inline functions are superior in every way, BAR NONE!

Do you consider:

#if defined (CODE_1)
// some code
#else if defined (CODE_2)
// other code
#endif

the use of macros?

[Siemel Naran]

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:c6******** *****@news.t-

JKop wrote:

Thus, concordantly and therefore, you most certainly _are_ taking up
memory by using a macro instead of a const global variable.
Furthermore, you may even use MORE memory with a macro; For example,
if you have the number "5" littered throughout your program, you're
not necessarily guaranteed that all of the "5"'s will be taken from
the same place in memory! There may be a unique "5" in memory for
every single seperate time you use it.

Actually, they might not even be taken from memory at all, or let's
better say from data memory. If you have a variable, it resides in
memory somewhere, and the compiler might need to create an instruction
that loads it from there. On assembler level that means there is an
instruction that says something like "load the value from memory
address 0xdeadbeef". If it's a macro, the literal 5 is usually directly
included in the instruction on assembler level, so the assembler
instruction would say "load the value 0x00000005". As you can see, the
instructions can be (and often are) of the same size, but in the first
case, you additionally need a memory location to save the value to (in
my example at address 0xdeadbeef). However, a constant can be used
"inline", just like the macro, so any decent compiler can also directly
put the literal 5 into the assembler instruction unless you try to take
its address, in which case the compiler needs to put it into data
memory to ensure it actually has an address. Since constants have
internal linkage by default, it would mean that each translation unit
that needs the address of the constant would need to store its own copy
of it in memory.

Very good answer. In my experience it is very rare to use address of a
constant, such as these:

const double pi=3.1415926535 8979323846;
namespace physics
{

const double hbar=1.05457259 0e-34; // Joule*second
const double hbarsquared=1.1 12123347e-68; // (Joule*second)^ 2
const double boltzman=1.3806 58000e-23; // Joule/Kelvin
const double elemcharge=1.60 2177330e-19; // Coulomb
const double lightspeed=2997 92458.0; // meter/second
const double dielectric0=8.8 54187817e-12; // Coulomb^2/Newton/meter^2
const double electron_mass=9 .1093897e-31; // kilogram

}

How come Superman could stop bullets with his chest,
but always ducked when someone threw a gun at him?

Good question.

[Siemel Naran]

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

JKop wrote:

As for macro functions: Similarly, there is absolutley NO JUSTIFICATION for their use. Inline functions are superior in every way, BAR NONE!

Do you consider:

#if defined (CODE_1)
// some code
#else if defined (CODE_2)
// other code
#endif

the use of macros?

Don't know about JKop, but this seems fine to me. How else to have code
compiled for Windows only, or Borland only, or debug mode only?

[Siemel Naran]

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

JKop wrote:

As for macro functions: Similarly, there is absolutley NO JUSTIFICATION for their use. Inline functions are superior in every way, BAR NONE!

Please describe how to implement the (standard library) offsetof macro in

terms of an inline function that is 'far superior' (or at least equally

inferior!).

Use the C++ pointer to member mechanism. The offsetof is only for C.

[Siemel Naran]

"Michiel Salters" <Mi************ *@logicacmg.com > wrote in message

JKop <NU**@NULL.NULL > wrote in message news:<YPKjc.587 8

As for macro functions: Similarly, there is absolutley NO JUSTIFICATION for their use. Inline functions are superior in every way, BAR NONE!

inline int BYTES_NEEDED_FO R_INTS ( int no_ints )
{
return no_ints * sizeof(int);
}
typedef char[ BYTES_NEEDED_FO R_INTS( 5 ) ] int5;

Does your compiler accept this?

BTW, is int5 above misplaced?

Anyway, that should be rewritten using structs and static const so that you
can use compile time constants. So basically I agree with JKop.

template <size_t N>
struct bytes_needed_fo r_ints
{
static const size_t result = N * sizeof(int);
};

typedef char int5[ BYTES_NEEDED_FO R_INTS<5>::resu lt ];