Hi All, I am being confused with the use of enum vs #define. Sometold me that enum is better and some #define. Well, as per my understanding while defining sequencial data i.e. 1,2,3,4... at that time enum is better as one doesn't has to write the number i.e enum Month { Jan, Feb, .... Dec }; But in case of random number defination, #define will be good. i.e #define TEMPERATURE 35 #define USL 45 #define LSL 25 Which one is good with respect to memory ? What are the advantages/disadvantages of both.
This will certainly help you: http://www.embedded.com/showArticle.jhtml?articleID=9900402
Hi Rene Don, Thanks for the url. This helps me a lot to understand the difference.
That article goes on at length about how Constant Objects may consume storage space. What it omits to mention is that this will also generate extra code to fetch the constant value from its storage location; ie it impacts on code size, data size, and execution speed. That article also omits to mention that
int const buffer_size = 256; char buffer[buffer_size];
One of the potential advantages of enum is that it allows the compiler to provide symbolic debug information. Unfortunately, Keil do not take advantage of this. :-( Not in C51, anyhow. :-(( See: http://www.keil.com/forum/docs/thread6863.asp
One of the potential advantages of enum is that it allows the compiler to provide symbolic debug information. Unfortunately, Keil do not take advantage of this. :-( Not in C51, anyhow. :-(( I do not use enum with the '51. The C standard states that if enum, then int. I can not afford the extra byte of data space. Erik
"The C standard states that if enum, then int." That's true, and is one of the potential disadvantages of enums - as mentioned in the article. However, most compilers have the option to store enums in 8 bits if they'll fit. Keil C51 always uses 8 bits if it can: http://www.keil.com/support/man/docs/c51/c51_ap_datastorage.htm "I can not afford the extra byte of data space." enum per se uses no data space. You might end up using some extra code space for immediate operands, though... Then again, 'C' assumes that everyting's an int unless specified otherwise, so you might get the same problem with #define and "raw" magic numbers...!
To a large degree, it's a matter of taste. I prefer enums when I have a number of related integer constants. Enums are clearly preferable when you don't care what the values are. But even when you do need to specify the values for all the constants, I like the mental grouping of an enum. Code documents itself better when you have the type, e.g. Error MyFunc(); clearly returns one of a particular set of error codes, whereas int MyFunc() might return one of the #define'd list for Unix errno, or maybe something else, or maybe those plus some idiosyncratic values -- who knows? If you have more than one set of return codes, which set does this function use? The more specific enum type name helps the tags facility in your editor, greps, debugging, and so on. A strict lint may give you some warnings about using enums as integers, for example if you add or or them, or pass an enum to an int. A const object is different from either an enum or a #define, particularly in C. In ANSI C, a const int takes up space just as a regular int; most compilers will also generate pointer references to this address rather than inlining the value. As a result, I rarely use const int's in C. (C++ has slightly different semantics, and so the choices are different there.) Every compiler I've ever used has the option to store enums in the smallest space possible. Usually it's even the default option. To force wider enums when using such an option, I usually throw in an extra unsigned value:
typedef enum { MyEnumA, MyEnumB, MyEnumForce16 = 7fff } MyEnum;
Keil C51 always uses 8 bits if it can: http://www.keil.com/support/man/docs/c51/c51_ap_datastorage.htm This must have happened when I left Keil for a good while and did not get update notes, it used to be standard C (always an int). Note; I did not "leave" Keil for any other reason than using a "non-Keil" processor, the XA, in combination with the '51 and running 2 different toolsets is, in my book, a no-no if avoidable. "I can not afford the extra byte of data space." enum per se uses no data space. this was in reference to the "forced" int. Erik
"it used to be standard C (always an int)." Yes - standard 'C' says "always int" But, like Drew, every compiler I've ever used has the option to store enums in the smallest space possible - including PC compilers! "this was in reference to the "forced" int." No - that's irrelevant. enums themselves do not use data space - they're just compile-time symbols for numeric values. As immediate operands they (and numeric literals, and #defined constants) would end up in code - not data - space!
"this was in reference to the "forced" int." No - that's irrelevant. enums themselves do not use data space - they're just compile-time symbols for numeric values. OK, we do not understand each other, so let me try again. Enum does not, in itself take any space, but in implementations that adhere to standard C making the enumerated variable an int, they do cost you one byte, if you otherwise would have used a char. Erik