|
Both But I use enums more and more. #defines polute the global namespace whereas enums are typically declared within a class. const int blah is another valid and more politically correct way of doing #def's.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
Neville Franks wrote:
#defines polute the global namespace
Do they really ? I don't think so, they are replaced by the preprocessor, before the C++ compilation.
const int do pollute the namespace when they are defined outside classes scope.
Max.
|
|
|
|
|
Well, technically no. But effectively, yes, sort of.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Maximilien wrote:
Do they really ? I don't think so, they are replaced by the preprocessor, before the C++ compilation.
What I meant was if you have #define FRED 123 in one header and someone else has #define FRED 456 in another header you are in trouble.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
yep! if it's your code, you need to fix it ...
you'll get a compilation warning :
c:\documents and settings\lincourt\my documents\testanotherthing\panel2.h(15) : warning C4005: 'TATA' : macro redefinition
c:\documents and settings\lincourt\my documents\testanotherthing\panel1.h(9) : see previous definition of 'TATA'
Max
|
|
|
|
|
Maximilien wrote:
yep! if it's your code, you need to fix it ...
This can be easier said than done. It gets even worse if you have third party code/libraries which happen to use the same #define name.
Very good reasons not to use #define's.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
that's another place where namespace come in handy ...
Max.
|
|
|
|
|
Maximilien wrote:
that's another place where namespace come in handy ...
I didn't think namespace effected #define's. Even if it did, I can't change the namespace used by third party code.
Just admit it #define's are bad.
Neville Franks, Author of ED for Windows. www.getsoft.com
Make money with our new Affilate program
|
|
|
|
|
Even though I wouldn't ban #define from the language, I can think of no place where I would use them when I could use an "enum". Even in the case of bit mask enums, I would still use them instead of #define.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
In our current projects, we have relegated #define to handling conditional compilation only. We've not found any cases where we couldn't handle things better using const 's, enum 's, or templates.
Software Zen: delete this;
|
|
|
|
|
I prefer enum because, #define XXXXXX never be seen by compilers. Removed by the preprocessor before the source code ever gets to a compiler. So, XXXXXX not entered into compiler symbol table.
Ahmet Orkun GEDiK
Technical Consultant
ASTRON Project Office
|
|
|
|
|
using enums in class or in another namespace should removes all semantic conflict of a symbol. Enum should be used for symbolic values, where the numerical value has no importance.
Using const <some type=""> ( or #define ) is better when the value is important and significant.
enum eAttachment
{
ATTACH_LEFT,
ATTACH_RIGHT,
};
const int iNudgeFactor;
const float fPI = 3.14;
...
Max.
|
|
|
|
|
As has been said, const int should be used rather than #define. An enum is a good idea where a number of values are logically grouped together, const *type* should be used where a value is unique. A #define does not pollute any namespace, it does not exist, the preprocessor replaces it with the value. Macros are generally evil, although I once lost a job at least in part because I knew this. I would also wrap any constants I create into a namespace, so the global namespace is unpolluted.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Christian Graus wrote:
Macros are generally evil, although I once lost a job at least in part because I knew this.
You gotta elaborate on this!
|
|
|
|
|
It's kind of a long story. The short version is I did some distance work, and one of my cow-workers, whom the boss held in high esteem ( and rightly so, may I add ) decided to give me a programming pop quiz. Being aware of the reasons not to use macros, I really had never used them and so failed the test (which involved macros ). I believe this was a pivotal moment in that person involved deciding that he did not support me having the position, which I was struggling with due to lack of guidance/information until AFTER I delivered things, at which point I was told I was doing it wrong. So they sacked me. I am still in awe of the whole process, to be honest, but I made enough money to buy a video camera, so that was better than nothing.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Christian Graus wrote:
but I made enough money to buy a video camera, so that was better than nothing.
<Entering Nick's Weird Memory> Was this when you did some work for CodeJock?</Enter Nick's Weird Memory>
Nick Parker
Not everything that can be counted counts, and not everything that counts can be counted. - Albert Einstein
|
|
|
|
|
Um... yeah. I never mention them when I bring it up because I don't want to get personal. I generally mention it in terms of 'things to be wary of when you work for someone in another hemisphere'. This time I just remembered how insulted I was to be asked how to write a min macro ( I provided two solutions, only one of which was correct, and as I said, the reason was that I never use macros ).
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Christian Graus wrote:
Um... yeah. I never mention them when I bring it up because I don't want to get personal.
Sorry, didn't mean to bring them up. I will shackle it away in memory from now on. Thanks for the "generic" tip though.
Nick Parker
Not everything that can be counted counts, and not everything that counts can be counted. - Albert Einstein
|
|
|
|
|
That's cool. Just forget you ever heard the name, OK ? :P
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
Christian Graus wrote:
Just forget you ever heard the name, OK ?
What name?
Nick Parker
Not everything that can be counted counts, and not everything that counts can be counted. - Albert Einstein
|
|
|
|
|
I was hoping you'd say that... :P
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
I avoid preprocessor where ever possible, as a general rule.
About defines... I personaly think enums are better b/c they do not polute global namespace. I put them into scope of my class and access them with CMyClass::VALUE1, CMyClass::VALUE2 (like in your exmaple).
|
|
|
|
|
"I avoid preprocessor where ever possible, as a general rule."
oh, I ment in C++...
with C this rule wouldn't be possible. But C++ introduced so many features which reduces use of preprocessor/precompiler to a vanishing minimum.
|
|
|
|
|
Enums are type safe which is a nice thingtm. They are also recognized by the compiler and can be displayed using the symbolic name in debuggers which is also a nice thingtm.
I use #define's sometimes though. But that's because all those countless hours of C-coding has affected my brain.
--
This space for rent.
|
|
|
|
|
Thank-you all for your comments. Now to convince about a half-dozen people to listen...
You've all had good arguments for enums.
Thanks
Brad
|
|
|
|