is there any significant difference or advantage in using either #define or const for constants, thanks

The main advantage in using constants over #defines is that constants are bound by programming rules (i.e. they are type safe) where #defines are just expanded blindly by the preprocessor.

Also, constants have a way of behaving in a debugger, since you can view them as a normal variable.

Edited by - I-Shaolin on July 27, 2000 10:52:05 PM

I go with I-Shaolin! (again)
Also:
- Using const will add a solid variable to your program, and make your .exe bigger. (probably neglectable)
- If you''re using C (without ++) you can''t use const for defining the size of an array for example (int Array[iSize]

quote: Original post by baskuenen

- Using const will add a solid variable to your program, and make your .exe bigger. (probably neglectable)

I think you got it the other way round. The #define will make the exe larger as the #define is pasted into several places rather than a memory ref when using a const, but the overall effect is negligble though..

Void: Depends...

    // use 100 ints#define LENGTH (100)int Array[LENGTH];// use 101 intsconst int LENGTH = 100;int Array[LENGTH];    

But the extra int still negligble though...

I must say, it feels a bit strange using const in combination with the array length! (as shown above)

Imagine you take the pointer to this const and typecast it to a normal pointer. Now you can still change this const value... Imagine if you do - it can really fuck up your program!!!

It may not be such a nice to do...but you can, and it gives me a strange unlogical feel for using the const this way...

quote: Original post by I-Shaolin

The main advantage in using constants over #defines is that constants are bound by programming rules (i.e. they are type safe) where #defines are just expanded blindly by the preprocessor.

Also, constants have a way of behaving in a debugger, since you can view them as a normal variable.

Edited by - I-Shaolin on July 27, 2000 10:52:05 PM

There you go being intelligent again. I find it hard to believe that no one ever hits on you. I find brains sexy. What does your name mean, I-Shaolin?
-Shadow

quote: Original post by baskuenen
Imagine you take the pointer to this const and typecast it to a normal pointer. Now you can still change this const value... Imagine if you do - it can really fuck up your program!!!

I was thinking about this, and about how solid the C++ specification usually is, so I looked it up. Straight out of MSDN:
"A pointer to a variable declared as const can be assigned only to a pointer that is also declared as const."
So you can''t actually do what you stated above
Not in Visual Studio anyway, it might not be in the C++ standard, though I suspect it is.




Give me one more medicated peaceful moment.
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important social functions will be disabled from now on.

I belive it is possible...
I think that I remember reading about that in Beginning Visual C++ 6.0 .

Edited by - NeRo on July 28, 2000 9:00:51 AM

A couple of other things...
As far as I know, the compiler is allowed to "inline" consts - like the preprocessor does with the #defines. Also, it should be noted that (to the best of my knowledge) c constants and c++ constants don't abide the same rules - c "const" doesn't define a new type, it only disallows change of the variable.

Also regarding pointers to consts:

const int i = 0;

int *ptr = &i // Isn't valid, flagged by compiler

int *ptr = const_cast < int *>(&i); //would work. probably undefined if you try to change i this way



Edited by - Armitage on July 28, 2000 9:35:33 AM