[Jacic]

Hi everyone. I was wondering what specific advantages and disadvantages const and #define give when coding.

Obviously, #define is a little simpler.

#define WHATEVER 42
const int WHATEVER = 42;

I think using #define takes no space to store the value, as it is replaced before compilation.

Some things are impossible to do with a #define, however.

#define ONE 1
#define TWO ONE + ONE

That would be easy using constants.

const int ONE = 1;
const int TWO = ONE + ONE;

So the rule of thumb is: 'if its incredibly simple, use #define, otherwise const', right?

Anything else that I'm missing?

[vividexstance]

No the rule is don't use the pre-processor, use the const construct. There is no type-checking during pre-processing, there is however type-checking for consts.

[anonymouscodder]

const respects scope and type, and the errors generated by the compiler are better.

In matter of performance I guess it's the same, one it's resolved before compilation but the other are really simply to optimize at compile time. For me it's a matter of organization which one to choose.

[Jacic]

Alright, good coding practices are important. Thanks for the info.

[NickDMax]

First of all lets deal with this:

Quote

I think using #define takes no space to store the value, as it is replaced before compilation.

-- This is more or less correct BUT it implies that the same is not true for a const. This is not generally true however. The compiler can (and usually does) just slip in the value of the const into the code where you use it -- except with the const you get type safety.

Now I said: "more or less true" because the number does get "stored" inline in the code. With integers this is normally ok because it saves us having to load a value by reference into a register (we can use immediate or a simple mov) and this is generally better for caching. However, there are times when it is less efficient for example in floating point operations which need to get pushed into special registers. SO -- sometimes it is better to store the value in 1 place rather than to repeat the value over and over around the code. When you use a constant you give the compiler a chance to make this decision during compile time (note however that if your turn on optimization the compiler will generally do this for even #define floating point values and literals... but it is something to think about).

That is not to say that #define constants have no use in code -- they do -- but the value generally involves really advanced or deep thinking. For example const values can not be used within other pre-processor logic. So for example one might establish a DEBUG_LEVEL constant and then use its value to determine what kind of debugging information gets displayed.

There are also Preprocessor-meta programming techniques such as advanced loops utilizing the #include directive that might use counters etc.

So -- in general it is just better to stick to C++'s type system for constants!

[CreamDelight]

I second those posts above that using C++ data types is much better for it checks before compiling, but i just want to clarify this code below..

Jacic, on 01 August 2011 - 01:53 PM, said:

Some things are impossible to do with a #define, however.

#define ONE 1
#define TWO ONE + ONE

That would be easy using constants.

const int ONE = 1;
const int TWO = ONE + ONE;

Actually you can do this with macros..
so for example in your statement above, i think you were trying to use it as an adder..
A macro like this can do the job..

#include <stdio.h>
#define ADD(a, B)/> a + b

void main()
{
        int x = 11;
	printf("%d\n\n", ADD(x, 6));
}

Macros also supports variable so i think it does the job..

But then again, stick with const types..

[PlasticineGuy]

#define ONE 1
#define TWO ONE + ONE

Funnily that works fine. It gets resolved as:

#define TWO 1 + 1

[NickDMax]

@CreamDelight -- No. Macros do NOT work like that. Macros are not "variables" that is they do not vary. The C preprocessor is a declarative language that does string substitution. When you do this:

#include <stdio.h>
#define ADD(a, b ) a + b

int main()
{
    int x = 11;
    printf("%d\n\n", ADD(x, 6));
    return 0;
}

and then run it past the preprocessor you get this:

<contents of stdio.h>

int main()
{
    int x = 11;
    printf("%d\n\n", x + 6);
    return 0;
}

All that happens when expanding ADD is the value passed for a is substituted in to the macro and the value of b is substituted in so for:

ADD(x, 6) you get the code: x + 6


Try this little program:

#include <stdio.h>
#define ADD(a, b ) a + b

int main()
{
    int x = 11;
    printf("%d\n\n", 10 * ADD(x, 6));
    return 0;
}

you might expect the output to be 10 * (11 + 6) = 170 right: but when you run the program you get 116 -- because the macro just pasted in the string of code: "x + 6" so this program is really:

printf("%d\n\n", 10 * 11 + 6);

and now operator* has higher precedence and is evaluated first, then the addition so you get 110 + 6 or 116.

another example from above is:

#define ONE 1
#define TWO ONE + ONE
...

printf("%d\n\n", TWO*10); //line becomes: printf("%d\n\n", 1 + 1*10);

The output is 11 rather than 20! because the preprocessor did not evaluate the value TWO it only did a substitution of the macro ONE into the the macro TWO and then when you use TWO it just substituted in the value 1 + 1 so the expression became 1 + 1*10.

Macros DO NOT evaluate expressions. Macros do NOT have variables because nothing varies - everything in the preprocessor language is done with string replacement. That is not to say that the preprocessor does not have a fairly bright programming environment -- you can do all kinds of neat things such as iteration and conditional logic -- for examples see these two snippets:

Selecting a language to compile for -- uses the preprocessor to to select messages in different languages.

Preprocessor Initialize Arrays -- uses iteration in the preprocessor to initialize arrays.

Advanced Preprocessor - a topic where I talk about XMacros - a technique for using a table to generate code structures such as enums and arrays of strings or case-statements etc.

Of course to really see the power of the preprocessor realized you need a library of functionality. See Boost::Preprocessor to see what can really be done. The library has for loops, while loops, lists, sequences, arrays -- it is nearly a full programming environment all built atop the declarative language of the preprocessor.

BUT -- as neat as I find macros -- they are dangerous because there is no type checking, no syntax checking (i.e. the preprocessor does not know C or C++ and will willing produce invalid code) and often macros hide syntax errors or subtle logic errors.

There is a reason why the convention is to name Macros in ALL_UPPER_CASE -- its to remind and warn programmers that what they are using is a macro and it may not work the same as a function or exactly be the constant they were hoping for.

Macros are generally designed to work in specific kinds of situations and generally cause trouble when that information is skewed between developers.

[Jacic]

@NickDMax Ah. I get it now. Thanks for your help.

[GWatt]

Just in case anyone wants to see examples of fairly complex/dangerous macros, here are some that are used in one of my university's lower level systems intro classes.

#define Full(c) (c != -1)
#define Empty(c) (c == -1)

#define CONCAT2(arg1, arg2) arg1 ## arg2
#define CONCAT(arg1, arg2) CONCAT2(arg1, arg2)

#define Begin() static void *pc = 0; if (pc) goto *(pc);

#define Return(x) \
do { \
        pc = CONCAT(&&_L, __LINE__); \
        return x; \
        CONCAT( _L, __LINE__) :; \
} while (0)

#define Finish() return 0;

#define Send(ch, v) while(Full(ch) ) Return(1); ch = v

#define Receive(ch, v) while(Empty(ch) ) Return(1); v = ch; ch = -1

What this macro suite does is imitate multithreading on a single core, single thread ARM chip. The reason it's done this way is to preserve timing while receiving a signal before we get to handling interrupts.

[CreamDelight]

NickDMax, on 02 August 2011 - 05:26 AM, said:

@CreamDelight -- No. Macros do NOT work like that. Macros are not "variables" that is they do not vary. The C preprocessor is a declarative language that does string substitution. When you do this:

Macros DO NOT evaluate expressions. Macros do NOT have variables because nothing varies - everything in the preprocessor language is done with string replacement. That is not to say that the preprocessor does not have a fairly bright programming environment -- you can do all kinds of neat things such as iteration and conditional logic -- for examples see these two snippets:

Ahh okay.. I get it..
I thought what I was doing were macros..
So how do you call something like that??
like this..

#define ADD(a, B)/> a + b

.. I thought macros were that simple.. heha..
BTW.. thanks for that explanation.

[NickDMax]

I think you are asking how to make a macro that can take two numeric arguments and add them?

that is: ADD(3, 2) will substitute in 5?

I see two patterns that could work.
#1 you could use tables. Basically encoding an addition table. Nice thing about this method is that you could probably write a program to generate the macros needed (heck I think a little regex would work).

the big down side is that you have to generate a VERY large table for this to work beyond anything simple. For example a 10x10 table would be 100 elements and would only let you add numbers between 0-9 a 256x256 table would need 65536 entries and may cause problems for the precompiler... so this is may be a simple way but probably not the best.

Spoiler

#define ADD_0_0/> 0
#define ADD_0_1 1
#define ADD_0_2 2
#define ADD_0_3 3
#define ADD_0_4 4
#define ADD_0_5 5
#define ADD_0_6 6
#define ADD_0_7 7
#define ADD_0_8 8
#define ADD_0_9 9
#define ADD_1_0 1
#define ADD_1_1 2
#define ADD_1_2 3
#define ADD_1_3 4
#define ADD_1_4 5
#define ADD_1_5 6
#define ADD_1_6 7
#define ADD_1_7 8
#define ADD_1_8 9
#define ADD_1_9 10
#define ADD_2_0 2
#define ADD_2_1 3
#define ADD_2_2 4
#define ADD_2_3 5
#define ADD_2_4 6
#define ADD_2_5 7
#define ADD_2_6 8
#define ADD_2_7 9
#define ADD_2_8 10
#define ADD_2_9 11
#define ADD_3_0 3
#define ADD_3_1 4
#define ADD_3_2 5
#define ADD_3_3 6
#define ADD_3_4 7
#define ADD_3_5 8
#define ADD_3_6 9
#define ADD_3_7 10
#define ADD_3_8 11
#define ADD_3_9 12
#define ADD_4_0 4
#define ADD_4_1 5
#define ADD_4_2 6
#define ADD_4_3 7
#define ADD_4_4 8
#define ADD_4_5 9
#define ADD_4_6 10
#define ADD_4_7 11
#define ADD_4_8 12
#define ADD_4_9 13
#define ADD_5_0 5
#define ADD_5_1 6
#define ADD_5_2 7
#define ADD_5_3 8
#define ADD_5_4 9
#define ADD_5_5 10
#define ADD_5_6 11
#define ADD_5_7 12
#define ADD_5_8 13
#define ADD_5_9 14
#define ADD_6_0 6
#define ADD_6_1 7
#define ADD_6_2 8
#define ADD_6_3 9
#define ADD_6_4 10
#define ADD_6_5 11
#define ADD_6_6 12
#define ADD_6_7 13
#define ADD_6_8 14
#define ADD_6_9 15
#define ADD_7_0 7
#define ADD_7_1 8
#define ADD_7_2 9
#define ADD_7_3 10
#define ADD_7_4 11
#define ADD_7_5 12
#define ADD_7_6 13
#define ADD_7_7 14
#define ADD_7_8 15
#define ADD_7_9 16
#define ADD_8_0 8
#define ADD_8_1 9
#define ADD_8_2 10
#define ADD_8_3 11
#define ADD_8_4 12
#define ADD_8_5 13
#define ADD_8_6 14
#define ADD_8_7 15
#define ADD_8_8 16
#define ADD_8_9 17
#define ADD_9_0 9
#define ADD_9_1 10
#define ADD_9_2 11
#define ADD_9_3 12
#define ADD_9_4 13
#define ADD_9_5 14
#define ADD_9_6 15
#define ADD_9_7 16
#define ADD_9_8 17
#define ADD_9_9 18
#define ADD(x, y) ADD_ ## x ## _ ## y

#include <iostream>
int main() {
    std::cout << ADD(0, 0) << ADD(0, 1) << ADD(0, 2) << ADD(0, 3) << ADD(0, 4) << ADD(0, 5) << ADD(0, 6) << ADD(0, 7) << ADD(0, 8) << ADD(0, 9) << std::endl;
    std::cout << ADD(1, 0) << ADD(1, 1) << ADD(1, 2) << ADD(1, 3) << ADD(1, 4) << ADD(1, 5) << ADD(1, 6) << ADD(1, 7) << ADD(1, 8) << ADD(1, 9) << std::endl;
    std::cout << ADD(2, 0) << ADD(2, 1) << ADD(2, 2) << ADD(2, 3) << ADD(2, 4) << ADD(2, 5) << ADD(2, 6) << ADD(2, 7) << ADD(2, 8) << ADD(2, 9) << std::endl;
    std::cout << ADD(3, 0) << ADD(3, 1) << ADD(3, 2) << ADD(3, 3) << ADD(3, 4) << ADD(3, 5) << ADD(3, 6) << ADD(3, 7) << ADD(3, 8) << ADD(3, 9) << std::endl;
    std::cout << ADD(4, 0) << ADD(4, 1) << ADD(4, 2) << ADD(4, 3) << ADD(4, 4) << ADD(4, 5) << ADD(4, 6) << ADD(4, 7) << ADD(4, 8) << ADD(4, 9) << std::endl;
    std::cout << ADD(5, 0) << ADD(5, 1) << ADD(5, 2) << ADD(5, 3) << ADD(5, 4) << ADD(5, 5) << ADD(5, 6) << ADD(5, 7) << ADD(5, 8) << ADD(5, 9) << std::endl;
    std::cout << ADD(6, 0) << ADD(6, 1) << ADD(6, 2) << ADD(6, 3) << ADD(6, 4) << ADD(6, 5) << ADD(6, 6) << ADD(6, 7) << ADD(6, 8) << ADD(6, 9) << std::endl;
    std::cout << ADD(7, 0) << ADD(7, 1) << ADD(7, 2) << ADD(7, 3) << ADD(7, 4) << ADD(7, 5) << ADD(7, 6) << ADD(7, 7) << ADD(7, 8) << ADD(7, 9) << std::endl;
    std::cout << ADD(8, 0) << ADD(8, 1) << ADD(8, 2) << ADD(8, 3) << ADD(8, 4) << ADD(8, 5) << ADD(8, 6) << ADD(8, 7) << ADD(8, 8) << ADD(8, 9) << std::endl;
    std::cout << ADD(9, 0) << ADD(9, 1) << ADD(9, 2) << ADD(9, 3) << ADD(9, 4) << ADD(9, 5) << ADD(9, 6) << ADD(9, 7) << ADD(9, 8) << ADD(9, 9) << std::endl;
    return 0;
};

which produces:

int main() {
    std::cout << 0 << 1 << 2 << 3 << 4 << 5 << 6 << 7 << 8 << 9 << std::endl;
    std::cout << 1 << 2 << 3 << 4 << 5 << 6 << 7 << 8 << 9 << 10 << std::endl;
    std::cout << 2 << 3 << 4 << 5 << 6 << 7 << 8 << 9 << 10 << 11 << std::endl;
    std::cout << 3 << 4 << 5 << 6 << 7 << 8 << 9 << 10 << 11 << 12 << std::endl;
    std::cout << 4 << 5 << 6 << 7 << 8 << 9 << 10 << 11 << 12 << 13 << std::endl;
    std::cout << 5 << 6 << 7 << 8 << 9 << 10 << 11 << 12 << 13 << 14 << std::endl;
    std::cout << 6 << 7 << 8 << 9 << 10 << 11 << 12 << 13 << 14 << 15 << std::endl;
    std::cout << 7 << 8 << 9 << 10 << 11 << 12 << 13 << 14 << 15 << 16 << std::endl;
    std::cout << 8 << 9 << 10 << 11 << 12 << 13 << 14 << 15 << 16 << 17 << std::endl;
    std::cout << 9 << 10 << 11 << 12 << 13 << 14 << 15 << 16 << 17 << 18 << std::endl;
    return 0;
};

This could be optimized to reduce some of the redundancy. For example there is no need for a macro for both ADD_4_5 and ADD_5_4 but you will still need a basic table of some kind to store results in.

#2 you could use a counting loop. This may require far fewer but still a lot of macros. There are different ways you could do this depending upon how much "infrastructure" you build. The Boost::Preprocessor library for example has macros to test for equality and tuples to hold arguments etc. so you could probably easily build some kind of for loop.

I would probably implement such this using something similar to my initialize arrays snippet building a structure like:



ADD(5, 3) becomes
ADD_1(ADD_1(ADD_1(5)))

then the ADD_1 macro just needs a table that says something like

#define ADD_1_0 1
#define ADD_1_1 2
#define ADD_1_2 3
#define ADD_1_3 4 
#define ADD_1_4 5 
#define ADD_1_5 6
#define ADD_1_6 7
#define ADD_1_7 8
#define ADD_1_8 9
#define ADD_1_9 10
#define ADD_1_10 11
#define ADD_1_11 12
#define ADD_1_12 13 
#define ADD_1_13 14
#define ADD_1_14 15 
#define ADD_1_15 16 
#define ADD_1_16 17
#define ADD_1_17 18
#define ADD_1_18 19
#define ADD_1_19 20

#define ADD_1_X(n) ADD_1_ ## n
#define ADD_1(n) ADD_1_X(n)

ADD_1(ADD_1(ADD_1(5)))

Since macro arguments are completely expanded before being substituted (if the argument is not used with # or ## anyway) we get:

ADD_1(ADD_1(ADD_1(5))) becomes 
ADD_1(ADD_1(ADD_1_X(5))) becomes 
ADD_1(ADD_1(ADD_1_5)) becomes 
ADD_1(ADD_1(6)) becomes
ADD_1(ADD_1_X(6)) becomes
ADD_1(ADD_1_6) becomes
ADD_1(7) becomes
ADD_1_X(7) becomes
ADD_1_7 becomes
8

So why did I need the macro ADD_1_X? because arguments to a macro are not expanded when used with the ## (concatenation operator) - so to ensure that they DID get expanded I needed to hide the concatenation operator.

Spoiler

#define ADD_1_0 1
#define ADD_1_1 2
#define ADD_1_2 3
#define ADD_1_3 4 
#define ADD_1_4 5 
#define ADD_1_5 6
#define ADD_1_6 7
#define ADD_1_7 8
#define ADD_1_8 9
#define ADD_1_9 10
#define ADD_1_10 11
#define ADD_1_11 12
#define ADD_1_12 13 
#define ADD_1_13 14
#define ADD_1_14 15 
#define ADD_1_15 16 
#define ADD_1_16 17
#define ADD_1_17 18
#define ADD_1_18 19
#define ADD_1_19 20

#define ADD_1_X(n) ADD_1_ ## n
#define ADD_1(n) ADD_1_X(n)

#define BUILD_MACRO_CHAIN(macro, init_arg, times) BUILD_MACRO_CHAIN_ ## times (macro, init_arg)
#define BUILD_MACRO_CHAIN_9(macro, init_arg) macro( BUILD_MACRO_CHAIN_8(macro, init_arg) )
#define BUILD_MACRO_CHAIN_8(macro, init_arg) macro( BUILD_MACRO_CHAIN_7(macro, init_arg) )
#define BUILD_MACRO_CHAIN_7(macro, init_arg) macro( BUILD_MACRO_CHAIN_6(macro, init_arg) )
#define BUILD_MACRO_CHAIN_6(macro, init_arg) macro( BUILD_MACRO_CHAIN_5(macro, init_arg) )
#define BUILD_MACRO_CHAIN_5(macro, init_arg) macro( BUILD_MACRO_CHAIN_4(macro, init_arg) )
#define BUILD_MACRO_CHAIN_4(macro, init_arg) macro( BUILD_MACRO_CHAIN_3(macro, init_arg) )
#define BUILD_MACRO_CHAIN_3(macro, init_arg) macro( BUILD_MACRO_CHAIN_2(macro, init_arg) )
#define BUILD_MACRO_CHAIN_2(macro, init_arg) macro( BUILD_MACRO_CHAIN_1(macro, init_arg) )
#define BUILD_MACRO_CHAIN_1(macro, init_arg) macro( init_arg )

#define ADD(n, m) BUILD_MACRO_CHAIN(ADD_1, n, m)

BUILD_MACRO_CHAIN(ADD_1, 10, 4)
ADD(12, 4)

-- if you run the above though a preprocessor you will get 14 and 16 respectively.

The nice thing about counting is that you can do a lot more with less. With the little version of ADD in the spoiler tags there I can not only add the number 0-9 but if I place the higher number in the first argument I can do any addition whose sum is less than 21.

Learning to program in the preprocessor is a fun exercise because you really have to re-think how you approach problems. The can be a lot of typing (and/or copy/paste) but you learn real quick to use RegEx or some kind of code generation (even the preprocessor) to generate your code for you. Think about that for a second: you use macros to help you write macros... is that like meta-meta programming?

The PROBLEM with learning to program in the preprocessor is that it really is mostly mental masturbation because there really is little NEED for advanced macros. i.e. you hardly ever use this stuff for all the same reasons you should not be using macros as constants.

[NickDMax]

So the "proper" way to add constants at run time is to just add them. expressions involving constants are evaluated at compile time.

When you have: cout << 5 + 6 << endl; the compiler does the addition for you.

to abstract more advanced calculations you can use template-metaprogramming OR with C++11 you can use constexpr which lets you to make constant expression functions (which use to require TMP):

So in GCC you can do:

#include <iostream>

//requores GCC with c++0x support turned on... vs2010 does not implment constexpr yet.
constexpr int fib(int n) {
    return (n < 2) ? 1 : fib(n-2) + fib(n-1);
}


using namespace std;

int main() {
    cout << fib(0) << endl;
    cout << fib(1) << endl;
    cout << fib(2) << endl;
    cout << fib(3) << endl;
    cout << fib(4) << endl;
    cout << fib(5) << endl;
    cout << fib(6) << endl;
    cout << fib(7) << endl;
    cout << fib(8) << endl;
    cout << fib(9) << endl;
    cout << fib(10) << endl;
    int n = 11;
    cout << fib(n) << endl; //executed at run time! (well... in theory)
    return 0;
}

And this is the same as writing:

int main() {
    cout << 1 << endl;
    cout << 1 << endl;
    cout << 2 << endl;
    cout << 3 << endl;
    cout << 5 << endl;
    cout << 8 << endl;
    cout << 13 << endl;
    cout << 21 << endl;
    cout << 34 << endl;
    cout << 55 << endl;
    cout << 89 << endl;
    int n = 11;
    cout << fib(n) << endl; //note the compiler may substitute the constant value of 11 in and
// evaluate the expression at compile time... but the point is that constexpr functions can be used
// with runtime or compiletime code.
    return 0;
}

because the constexpr function is evaluated at compile time.

In visual studio 2010 which does not implement this keyword yet you still have to use TMP so you can do something like:

#include <iostream>

using namespace std;

template<int N>
struct Fib {
    enum {
        value = Fib<N-2>::value + Fib<N-1>::value,
    };
};

template<>
struct Fib<0> {
    enum {
        value = 1,
    };
};

template<>
struct Fib<1> {
    enum {
        value = 1,
    };
};

int main() {
    cout << Fib<1>::value << endl;
    cout << Fib<2>::value << endl;
    cout << Fib<3>::value << endl;
    cout << Fib<4>::value << endl;
    cout << Fib<5>::value << endl;
    cout << Fib<6>::value << endl;
    cout << Fib<7>::value << endl;
    cout << Fib<8>::value << endl;
    cout << Fib<9>::value << endl;
    cout << Fib<10>::value << endl;
    return 0;
}

Of course this goes crazy and will not compile if you try Fib<-1>::value.
If you are like me, you might ask: Why didn't you use the ?: operator to check for < 2 like you did int he constexpr? -- because in TMP compile time the compiler evaluates both the true and false conditions of the ?: operator (it needs to verify they evaluate to the same type) so the "false" condition in N < 2 ? 1 : Fib<N-2>::value + Fib<N-1>::value would evaluate even if the value is not used.

[ishkabible]

yummy TMP,i whooped up an integer square root for this, took me a bit but i got it

#include <iostream>

template<int n, int x = 1, int k = 0>
class Sqrt {
public:
	enum {
		value = Sqrt<n, (x + (n/x))/2, k + 1>::value
	};
};

template<int n, int x>
class Sqrt<n, x, 20> {
public:
	enum {
		value = (x + (n/x))/2
	};
};

int main() {
	std::cout<<Sqrt<49>::value;
}

it uses a place holder(k), if k gets to 20 then the recursion stops. so the precision can be adjusted if needed. im working on how to make the precision arbitrary.

edit:
20 seems to work preety good though, it may even be overkill. std::cout<<Sqrt<46340*46340>::value; prints 46340 but 46341*46341 is bigger than an integer can hold

edit2: 18 is all that is needed, 20 is over kill by 2

This post has been edited by ishkabible: 03 August 2011 - 11:06 AM

[NickDMax]

neat! Now do it in the preprocessor!