🔒 Locked

C++ : #define vs enum/const

Started by Teh Evil Mar 9, 2004 at 1:28 AM 25 replies 3.9k views

Original Post

Mar 9, 2004 at 1:28 AM

I had an argue with my friend last night about if it is a good programming practice to use a LOT of macro definitions for constants and not to use const or enum. I define my constants this way:

namespace Hell
{
   static const Flag0 = 0x1;
   static const Flag1 = 0x2;

// or if it is in a class, I use

   class Heaven
   {
      enum Flags
      {
         Flag0 = 0x1,
         Flag2 = 0x2,
      };
   }
}

he uses it as follows:


#define Flag0 0x1
#define Flag1 0x2

// even more like


class CoolBuffer
{
#define CB_NOTSOCOOL 1
#define CB_NOTEVENCOOL 2
    int Flags;
};
//... etc

... and he ignours all the C++ fancy capabilities that I love. I tried convincing him, but since he stands for the fact that "Microsoft uses macros, then it is correct! Are we better than microsoft?" I couldn't change any bit of his mind. So guys, plz give me a hand on this. or maybe correct me if I am wrong. Thanks in advanced That Was Teh Evil ^^ [edited by - teh evil on March 9, 2004 2:49:18 AM]

Thek

Mar 9, 2004 at 1:35 AM

It has been my experience both in school and in the industry that macros can reduce readability of code. In a team environment, it is best to write code in a way that is immediately apparent for other programmers to pick up.

Having said that, using #define to define a constant really isn't hard to read. So, I think you're both right. Macros can be bad, but mostly when it hurts readability. Personally, I use the static const approach, but that's a style thing more than an actual "good coding law."

(edit) I should say a little more... I think defines can be bad when they are used in excess or outside of global scope. In place of a large number of defines an enum is much better, and much more object oriented. Defines are generally considered ok for global constants, rather than class related constants.

my two cents,
Thek

[edited by - Thek on March 9, 2004 2:40:02 AM]

Beer Hunter

122

Beer Hunter

Mar 9, 2004 at 1:45 AM

Something.

iMalc

182

iMalc

Mar 9, 2004 at 2:14 AM

If you want the short answer then you are right and he is wrong. It is generally accepted that #defines are for the most part bad coding style if purely to hold constant values.

However there are some times where it is better to use a #define. For example something that may be a constant now, but you might like to substitute a non-constant expression some time in the future.

Tell your friend to read some books.

Teh Evil

Author

Teh Evil

Mar 9, 2004 at 6:18 AM

Thanks guys..

quote:
Original post by iMalc

Tell your friend to read some books.

well, in fact he is, more like... hmmn... My boss O_O

hewhay

Mar 9, 2004 at 6:35 AM

macros are evil #1 #2 #3 #4

[edited by - hewhay on March 9, 2004 7:37:18 AM]

[edited by - hewhay on March 9, 2004 7:38:29 AM]

[edited by - hewhay on March 9, 2004 7:39:04 AM]

hewhay

Mar 9, 2004 at 6:49 AM

btw you code aren''t analogous, while your provides for identifier collisions, his doesn''t, which alone should win the "good programming practice" qualification

alexk7

Mar 9, 2004 at 7:33 AM

Macros can''t be defined in a local scope. You have to invent some stupid prefix to prevent identical names. If they are defined in a header file, you get a lot of macro junk in the global namespace. That''s why I hate to include windows.h.

The only place where macros are useful is to control conditional compilation.

Teh Evil

Author

Teh Evil

Mar 9, 2004 at 10:15 AM

Of course I cannot post this to him, then how am I supposed to deal with this?

hewhay

Mar 9, 2004 at 10:38 AM

does he force you to use macros?
i he doesn''t just show me how much better the other way is by programming that way :-)

Teh Evil

Author

Teh Evil

Mar 9, 2004 at 11:10 AM

show what? you ? me? why?

anyway... nope, he does not, but I build things, and he change them when he gets it...

nevermind.

ToohrVyk

238

ToohrVyk

Mar 9, 2004 at 11:15 AM

void Load( long Pack, long Sprite );
#define EXPLOSION_FRAME_1 18,33
void main( void ) { Load( EXPLOSION_FRAME_1 ); }

A decent use of #defines, as a coding process accelerator, IMHO

Victor Nicollet, INT13 game programmer

wild_pointer

152

wild_pointer

Mar 9, 2004 at 11:19 AM

It really doesn''t make all that much difference in your example, using #define as bit flags or constants, that is.

Don''t misuse the term macro. These are not macros, and as such not subject to most of the many arguments against macros.

antareus

Mar 9, 2004 at 11:30 AM

Excepting scope issues, it seems to be an entirely stylistic difference. Macros are traditionally in all caps anyway, so the risk of collision is fairly low (unless you make your types all caps, but I won''t go there). I don''t see how one is more right than the other.

quote:
anyway... nope, he does not, but I build things, and he change them when he gets it...

Then it sounds like a convention should be established and followed.

_the_phantom_

496

_the_phantom_

Mar 9, 2004 at 11:53 AM

Well, scoping issues are a pretty major issue imo, more so for anything remotely large, last thing you want to be doing is chasing your tail around looking for an error which tracks back to a define somewhere replacing something you didnt think it would replace. This also comes under the header of ''the pre-processor is dumb''.

Also, you can ''undefine'' a defined thing and even change its meaning, which can confuse things, const varibles and enums cant be monkeyed with.

You can use const varibles to control conditional compilation as well using the compilers dead code removeal system to remove things which shouldnt be in release code (there was a thread recently which mentioned this), thus sidesteping the pre-processor for that section as well (added advantage here, even dead code is syntax checked, #defined out code isnt)

Personaly speaking, in my last project aside from include guards (which i''ve replaced in the next iteration with #pragma once) and a couple of instances where i had to talk to the winsock library i didnt use any defines, instead prefering the C++ way of doing things.

hewhay

Mar 9, 2004 at 11:58 AM

quote:
Original post by antareus
Excepting scope issues, it seems to be an entirely stylistic difference.

You should read the links that i provided

_DarkWIng_

Mar 9, 2004 at 12:02 PM

quote:
Original post by _the_phantom_
You can use const varibles to control conditional compilation as well using the compilers dead code removeal system to remove things which shouldnt be in release code (there was a thread recently which mentioned this), thus sidesteping the pre-processor for that section as well (added advantage here, even dead code is syntax checked, #defined out code isnt)

Could you give me the link to the thread about conditional compilation. I''m interested in getting rid of that part via const values.

You should never let your fears become the boundaries of your dreams.

hewhay

Mar 9, 2004 at 12:08 PM

i haven''t read the thread he mentions but it guess i has something to do with smart copilers removing code not used something like


if (false) {
 // the compiler may be smart enough to remove anything

 // here since it is never run

}

now please note that i haven''t tested this, nor have any knowledge about this, is just a guess

daveangel

Mar 9, 2004 at 12:10 PM

"I tried convincing him, but since he stands for the fact that "Microsoft uses macros, then it is correct! Are we better than microsoft?" I couldn''t change any bit of his mind"
well let him know that even MS has changed it''s evil ways cuz their new and future language c# doesn''t even support them!

If God played dice, He''d win.
—Ian Stewart, Does God Play Dice? The Mathematics of Chaos

antareus

Mar 9, 2004 at 1:20 PM

quote:
Original post by hewhay
You should read the links that i provided

We are talking about using macros for constants.

Not macros that token paste.
Not macros with multiple lines.
Not macros with if statements.
Not macros that are meant to be inlined functions.

I do not accept the statement "macros are evil" in the context of constants without additional evidence.

quote:
Well, scoping issues are a pretty major issue imo, more so for anything remotely large, last thing you want to be doing is chasing your tail around looking for an error which tracks back to a define somewhere replacing something you didnt think it would replace. This also comes under the header of ''the pre-processor is dumb''

A poor use of the preprocessor causes problems? Who would have thought!

quote:
(which i''ve replaced in the next iteration with #pragma once)

Now you''re using nonstandard preprocessor directives.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.