Thread: What type is a macro constant?

As the title says.
If you have to put number <define> NUMBER 125 it will assign to it an int type because its somehow "best fit"? or if NUMBER was 160.5 itll assign float? Or its somehow type free?

And what if its a 1 or 0. Itll automaticall put it in a bit field byte?

Macros are replaced with their defined expressions by the preprocessor. You can infer the resulting type from the defined expression and other surrounding expressions.

There is no assignment. NUMBER will be replaced with 125, which is an int (integer constants have type int unless they're too large). If you have #define NUMBER 160.5, then NUMBER will be replaced with 160.5, which is a double.

Macros do not have a type. Macros are essentially search and replace, which means macros don't really exist as far as the compiler is concerned (they disappear after pre-processing). If it's 1 or 0, the type will be int, because 1 and 0 are ints.

This can be somewhat problematic:

Code:

#define MAX 100000

So when you use MAX in your code, will it have (or be replaced with an expression that has) the type int? Maybe. But what if int is 16 bits? Then 100000 will be a long. This isn't usually going to be a problem, but is something to watch out for.

Quick answer: The type of a macro (conceptually) is the type of the expression that you used to define your macro.

Doh! Stupid question.

Does this substitution concept work the same way with enumerations or are enumerations ints?

enums are their own type. For example.

Code:

 enum state_t {NORMAL_STATE, COMMENT_STATE, BLOCK_COMMENT_STATE, STRING_STATE, CHAR_STATE};

If you omit a type name, it is an anonymous type, just like similar unions or structs. C's type safety rules are lax enough that it often makes no practical difference, though.

Another thing. a Macro constant applied to bit fields... Would you simply define a bit flag like any other constant?:

<define> KEYWORD 01

Originally Posted by MK27

WRT macro functions, the preprocessor substitutes the outcome of the function, not the actual code.

Nope! it plugs in the code that the macro function stands for.

Another thing. a Macro constant applied to bit fields... Would you simply define a bit flag like any other constant?:

<define> KEYWORD 01

I've never actually used bit fields, but I don't see why it wouldn't work.

FYI, 01 is an octal number.

Originally Posted by Vespasian

Another thing. a Macro constant applied to bit fields... Would you simply define a bit flag like any other constant?:

<define> KEYWORD 01

That wouldn't create a bit-field, tho' a 2 bit wide field can be initialized to that value.


[Edit] Never mind I didn't read the post right.

Originally Posted by Vespasian

Another thing. a Macro constant applied to bit fields... Would you simply define a bit flag like any other constant?:

<define> KEYWORD 01

As whiteflags pointed out, yes, 01 would work, and yes, it is an octal number. When people define offsets for bitfields, some use octal, but most of them use hex or bit-shifting:

Code:

#define USING_HEX_BIT_0    0x01
#define USING_HEX_BIT_1    0x02
#define USING_HEX_BIT_2    0x04
#define USING_HEX_BIT_3    0x08

#define BIT_SHIFT_BIT_0    1 << 0
#define BIT_SHIFT_BIT_1    1 << 1
#define BIT_SHIFT_BIT_2    1 << 2
#define BIT_SHIFT_BIT_3    1 << 3

The advantage of the second method is that you can easily see what bit number you're using by looking at the 0, 1, 2, 3, versus having to translate from hex. This can make a difference when you start getting above bit number 8 or 16, and your hex constants become quite long.

Theres some sick stuff on bit fields. K&R admitedly says that the full details cant be delved into. Theres other features of "padding" etc... wtf. Any good online tuts for C bit fiddling?

On the other hand, there is also this thing called bitfields which are a specialization of structs.

Originally Posted by Wikipedia

Kernighan and Ritchie's book, The C Programming Language, describes a method for defining and accessing fields directly. Using this method, bitwise operators are not needed as bit members can be accessed the same as members of a structure without the need to create a object-oriented class like the one above. An example using C's struct keyword and C++'s bool data type follows:

Code:

typedef struct Preferences {
    bool likesIceCream : 1;
    bool playsGolf     : 1;
    bool watchesTv     : 1;
    bool readsBooks    : 1;
} Preferences; 
 
Preferences fred;
fred.likesIceCream = true;
fred.playsGolf     = true;
fred.watchesTv     = true;
fred.readsBooks    = false;
 
if (fred.likesIceCream) {
    /* ... */
}

Which is the entire reason I said I haven't use them before.

I actually learned all about bits without understanding they were "fields". I think I will be able to go my entire career and never have to use bit fields. However,

Theres other features of "padding" etc... wtf.

There is such a thing as a "packed struct" and that is when you start caring about padding and byte alignment.