Thread: which consumes more memory....

Code:

Following declaration
#define IDLE_ST   0x01
#define RX_ST      0x02 
#define TX_ST      0x03
#define NO_ST     0x04

                   or
 
typedef enum {
                IDLE_ST =0x01,
                RX_ST ,  
                TX_ST , 
                NO_ST,     
             }teAcessCtrl;

//Application
     Statemachine()
    {
        switch(state)
        {
               case IDLE_ST :
                     break;
               case RX_ST :
                     break;
               case TX_ST  :
                     break;
               case  NO_ST :
                     break;

          }
    }

Using 32-bit microcontroller....

If some one explain me the memory consumption differences b/w the declarations.

2.Does static declarations of function's increase memory consumptions?

Thanks all in advance

Thanks....

How much will the following enum declaration consume, being a 32 bit machine...

will each member within the enum consume a memory space of 4 bytes (size of int)....or something else......

Originally Posted by grumpy

Generically a type declaration is a compile-time entity and there is no general reason for there to be associated space overhead at run time unless variables of that type are defined. It is true that some compilers (particularly when doing "debug" compiles) do include such type information in object files and therefore executables, but there is nothing (other than the desire to support debugging) making that necessary. In other scenarios (eg a modern optimising compiler doing a "release" build) there will be no associated overhead.

Assumption is enum is defined.........

@quzzah......
In what way does an enum consume more memory?....


How much will the following enum declaration consume,considering a 32 bit machine...
will each member within the enum consume a memory space of 4 bytes (size of int) when defined......i.e about 4x4 = 16bytes....or something else......

will each member within the enum consume a memory space of 4 bytes (size of int) when defined......i.e about 4x4 = 16bytes....or something else......

Definitely not that.

Enums are just for the compiler to make sure you can't assign other things to an int of the enum type (note that checks are done at compile-time). They are otherwise just like macros. The only possibility that it increases the size of the object file is that (like grumpy pointed out) type information is added to the object file for debugging purposes.

The main difference between macros and enums is that macros are true compile-time constants while enums are runtime constants.
Macro substitution is a copy-paste job done by the compiler and thus no memory is actually set aside for the substitution string.
The enum type object teAcessCtrl consumes storage equal to the implementation-defined value of sizeof(int).

Originally Posted by grumpy

Not true. Text substitution of macros is implemented before the compilation phase. The individual values of enums are fixed at compile time.

Perhaps then there's disagreement on what a compile-time constant is?

AFAIK a compile-time constant is one whose value is completely know at the time of compilation ie after the C preprocessor (cpp) has scanned the source file. The compiler invokes cpp automatically not as a part but as a sort of prelude to the compilation phase so methinks we are on the same page even tho our interpretation of compile-time constant differs.

Originally Posted by grumpy

In fact, some (moderately advanced) programming techniques rely on the fact that values of enumerations are formally compile-time constants.

Ain't I saying the same thing? Enumerators are evaluated much like the #defines but not objects of that enum type which are runtime variables, as in

Code:

enum boolean {FALSE, TRUE} flags;

Object flags is a runtime variable of type enum boolean but enumerators FALSE and TRUE aren't. Their values are compiler-generated with FALSE starting at zero.

Originally Posted by grumpy

There is no general requirement that sizeof(any enumerated type) be equivalent to sizeof(int).

Not according to the ANSI std it's not which specifically states that enumerators are named constants of type int.
However, you can change them to short, long or long long but their default type is always int, which is why

Code:

sizeof teAcessCtrl == sizeof(int)

Originally Posted by laserlight

hmm... but if you use that definition, then "macros are true compile-time constants" is absurd by definition since macros do not exist at compile time (Oh, and I think that "macros do not exist at compile time" was the point that you were trying to make.)

I agree they really are "substitution strings" aka placeholders / links and the word compile-time constant is a misnomer.
I am trying to avoid acronyms even though they are jumping out at me while replying to your post.

Originally Posted by laserlight

Good point: I assumed that grumpy was correct, but it appears that the C and C++ standards differ on this point.

I'm not sure what the C++ specification has to say about enums? But do enlighten me on it.
That is also the reason why enumerators can be used as array subscripts.

Originally Posted by laserlight

That said, I think that this statement is still wrong:

teAcessCtrl is not an object, but a type alias. Consequently, I believe that we can expect no storage consumption difference.

ITA [sorry couldn't help ] totally missed that typedef keyword before the enum declaration.
So yep! it's just an alias for that enum type and hence consumes no storage.

Originally Posted by laserlight

But wait: grumpy was talking about the enum type itself, and for that I believe that grumpy is still correct.

which is what?

IMHO you're confusing default type sizes with the explicitly specified ones. In other words

Code:

enum var {x, y, z} obj;             /* here sizeof obj == sizeof(int) according to the ANSI std ie the default */
short enum var {x, y, z} obj;       /* here sizeof obj == sizeof(short) */
long enum var {x, y, z} obj;        /* here sizeof obj == sizeof(long) */
long long enum var {x, y, z} obj;   /* here sizeof obj == sizeof(long long) */