which consumes more memory....

This is a discussion on which consumes more memory.... within the C Programming forums, part of the General Programming Boards category; Code: Following declaration #define IDLE_ST 0x01 #define RX_ST 0x02 #define TX_ST 0x03 #define NO_ST 0x04 or typedef enum { IDLE_ST ...

  1. #1
    Registered User
    Join Date
    Apr 2009
    Posts
    139

    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

  2. #2
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Macros are just text substitution at compile time. An enumeration would have to take a bit of space some place, just because it's actually defining a new type.


    Quzah.
    Hope is the first step on the road to disappointment.

  3. #3
    Registered User
    Join Date
    Apr 2009
    Posts
    139
    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......

  4. #4
    Registered User
    Join Date
    Jun 2005
    Posts
    6,658
    Quote Originally Posted by quzah View Post
    Macros are just text substitution at compile time. An enumeration would have to take a bit of space some place, just because it's actually defining a new type.
    Not true. 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.

    As to the original question .... the possible values of the enumerated type are known at compile time so, generally, the only memory overhead required is based on the type of the "state" variable (is it an int, or is it the enum type?). The size of the enum type is up to the compiler.

    Most modern compilers implement switch blocks as a jump table, so the overhead will be the same for both your methods.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  5. #5
    Registered User
    Join Date
    Apr 2009
    Posts
    139
    Quote Originally Posted by grumpy View Post
    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......

  6. #6
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    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.

  7. #7
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,058
    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).

  8. #8
    Registered User
    Join Date
    Jun 2005
    Posts
    6,658
    Quote Originally Posted by itCbitC View Post
    The main difference between macros and enums is that macros are true compile-time constants while enums are runtime constants.
    Not true. Text substitution of macros is implemented before the compilation phase. The individual values of enums are fixed at compile time.

    In fact, some (moderately advanced) programming techniques rely on the fact that values of enumerations are formally compile-time constants.
    Quote Originally Posted by itCbitC View Post
    The enum type object teAcessCtrl consumes storage equal to the implementation-defined value of sizeof(int).
    There is no general requirement that sizeof(any enumerated type) be equivalent to sizeof(int).
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  9. #9
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,058
    Quote Originally Posted by grumpy View Post
    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.
    Quote Originally Posted by grumpy View Post
    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.
    Quote Originally Posted by grumpy View Post
    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)

  10. #10
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,303
    Quote Originally Posted by itCbitC
    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.
    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.)

    Quote Originally Posted by itCbitC
    Not according to the ANSI std it's not which specifically states that enumerators are named constants of type int.
    Good point: I assumed that grumpy was correct, but it appears that the C and C++ standards differ on this point.

    That said, I think that this statement is still wrong:
    Quote Originally Posted by itCbitC
    The enum type object teAcessCtrl consumes storage equal to the implementation-defined value of sizeof(int).
    teAcessCtrl is not an object, but a type alias. Consequently, I believe that we can expect no storage consumption difference.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  11. #11
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,058
    Quote Originally Posted by laserlight View Post
    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.
    Quote Originally Posted by laserlight View Post
    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.
    Quote Originally Posted by laserlight View Post
    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.

  12. #12
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,303
    Quote Originally Posted by itCbitC
    I'm not sure what the C++ specification has to say about enums? But do enlighten me on it.
    I think that what is important is what it does not say about enums: unlike the C standard, it does not mandate that the "identifiers in an enumerator list are declared as constants that have type int and may appear wherever such are permitted", but chooses instead to mandate that they "are declared as constants, and can appear wherever constants are required" and that the "constant-expression shall be of integral or enumeration type".

    EDIT:
    But wait: grumpy was talking about the enum type itself, and for that I believe that grumpy is still correct.
    Last edited by laserlight; 06-27-2009 at 12:53 PM.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  13. #13
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,058
    Quote Originally Posted by laserlight View Post
    But wait: grumpy was talking about the enum type itself, and for that I believe that grumpy is still correct.
    which is what?

  14. #14
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,303
    Quote Originally Posted by itCbitC
    which is what?
    That the sizeof an enumeration type is not required to be equal to sizeof(int). The C standard does not require this, at least not in section 6.7.2.2 of C99. The C++ standard defines the sizeof the enumeration type as equal to the sizeof the underlying type.

    Sorry if I confused you though: it slipped my mind that the sizeof an object of an enumerator type has to be equal to the sizeof that enumeration type. As such, grumpy has to be correct either way: the restriction that the "identifiers in an enumerator list are declared as constants that have type int" just means that the constant expression used to initialise an enumerator must not be of a type with a range larger than that of int. The underlying type may well be an integral type with a range that is a subrange of int.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  15. #15
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,058
    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) */

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 4
    Last Post: 01-13-2008, 02:14 AM
  2. Question regarding Memory Leak
    By clegs in forum C++ Programming
    Replies: 29
    Last Post: 12-07-2007, 01:57 AM
  3. Memory problem with Borland C 3.1
    By AZ1699 in forum C Programming
    Replies: 16
    Last Post: 11-16-2007, 11:22 AM
  4. reading files into memory
    By bobthebullet990 in forum C Programming
    Replies: 3
    Last Post: 11-30-2005, 03:39 PM
  5. Shared Memory - shmget questions
    By hendler in forum C Programming
    Replies: 1
    Last Post: 11-29-2005, 02:15 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21