Help with C language macro stringification

[Back2Volts]

I have this macro which works fine

#define LA_TRACE_PORT_DR     (CYREG_PRT0_DR)

but I would like to use a define for the "0", so I am looking for something like the following (with proper syntax)

#define LA_TRACE_PORT_NUM    "0"

#define LA_TRACE_PORT_DR     ("CYREG_PRT#LA_TRACE_PORT_NUM#_DR")     

What is the proper syntax in the last two defines to come up with the equivalent of the first one?     You can imagine that I have tried a few silly variations before I came to post here.     I am not sure it makes a difference, but I am using gcc.

Tony

[cv007]

#define LA_TRACE_PORT_NUM       0
#define _LA_TRACE_PORT_DR(n)    (CYREG_PRT#n#_DR)
#define LA_TRACE_PORT_DR(n)     _LA_TRACE_PORT_DR(n) 

use-
LA_TRACE_PORT_DR(LA_TRACE_PORT_NUM)

You need the second define so LA_TRACE_PORT_NUM gets processed/reduced.

[NorthGuy]

Code: [Select]

#define LA_TRACE_PORT_NUM 0
#define CONCAT3(a,b,c) a##b##c
#define LA_TRACE_PORT_DR_PROTO(x) (CONCAT3(CYREG_PRT,x,_DR))
#define LA_TRACE_PORT_DR LA_TRACE_PORT_DR_PROTO(LA_TRACE_PORT_NUM)
Usage (should print 15):

Code: [Select]

#define CYREG_PRT0_DR 15
int main(void)
{
  printf("%d\r\n",LA_TRACE_PORT_DR);
}

[legacy]

(don't abuse the macro-processor)

[SimonR]

(don't abuse the macro-processor)

Good point, but its just so tempting

[Back2Volts]

Thank you guys.   I have it working and I promise I will try to avoid macros 

Tony

[SimonR]

Don't avoid them, just be careful how you use them.

[Kalvin]

You may want to familiarize yourself to X Macros: https://en.wikipedia.org/wiki/X_Macro Check also the article references. X Macros are handy things to know. However, do not overuse them

[Hypernova]

(don't abuse the macro-processor)

What good is power if you can't abuse it? 

[legacy]

What good is power if you can't abuse it? 
[/quote]

( eh, when are you in a rush, and ...
you find that the macro processor has just done a mess
May God save the Queen)

[Hypernova]

What good is power if you can't abuse it? 

( eh, when are you in a rush, and ...
you find that the macro processor has just done a mess
May God save the Queen)

Hence you are supposed to dish out macro gymnastics in small doses at a time.

The most complex macro I've done generated inline assembly statements from a standard string declaration. TI's C2000 series have 16bit chars so every string takes up double the size. For reasons  unknown the statements to define "packed" strings are available only in assembly.

[NorthGuy]

( eh, when are you in a rush, and ...
you find that the macro processor has just done a mess
May God save the Queen)

Macros don't make mess. People make mess.

People who don't like macros usually make more mess

[legacy]

( eh, when are you in a rush, and ...
you find that the macro processor has just done a mess
May God save the Queen)

Macros don't make mess. People make mess.

People who don't like macros usually make more mess

People like the person with whom one works, especially in a profession or business?
Sure, and it's a basket of plus all the time

[MarkS]

I have it working and I promise I will try to avoid macros 

Use macros to define constants. The macro processor is rather powerful and you can do a lot with it, but the more you do, the harder it gets to debug the code. If you need the macro to operate as a function, write a function.

[andyturk]

Use macros to define constants.

Please don't.

You shouldn't use macros for anything that you can do in the language itself. It's much better to define numeric constants as enums. E.g.,

Code: [Select]

enum {
  FOO = 0x00000001u
};

is preferable to:

Code: [Select]

#define FOO 0x0000001u


[hamster_nz]

Use macros to define constants.

Please don't.

You shouldn't use macros for anything that you can do in the language itself. It's much better to define numeric constants as enums. E.g.,

Code: [Select]

enum {
  FOO = 0x00000001u
};

is preferable to:

Code: [Select]

#define FOO 0x0000001u


Ew! declaring things as unnamed, unused enums so you can use them as constants? That seems so dirty!

At least it gets around the errors when you use a const to size an array:

Code: [Select]

$ cat c.c
const int sector_size = 512;

unsigned char sector[sector_size];

int main(int argc, char *argv[]) {
  return 0;
}
$ gcc -o c c.c
c.c:3:15: error: variably modified ‘sector’ at file scope
 unsigned char sector[sector_size];
               ^

But this works:

Code: [Select]

enum { sector_size = 512 };

unsigned char sector[sector_size];

int main(int argc, char *argv[]) {
  return 0;
}


Me? I'ld take "#define SECTOR_SIZE (512)" any day.... but that you never know, it might grow on me.

I might even make a macro for it!

[NorthGuy]

You shouldn't use macros for anything that you can do in the language itself.

The pre-processor is the part of the C language.

[legacy]

The pre-processor is the part of the C language.

Well, physically it's an external tool, since everything that begins with "#" (e.g. #define) is not handled by CC, it's pre-processed by CPP.

C source & H header -> macro expansion (by CPP) -> object file (by CC).

[NorthGuy]

The pre-processor is the part of the C language.

Well, physically it's an external tool, since everything that begins with "#" (e.g. #define) is not handled by CC, it's pre-processed by CPP.

C source & H header -> macro expansion (by CPP) -> object file (by CC).

The C language is not concerned with the implementations. It is only concerned with the results:

"The semantic descriptions in this International Standard describe the behavior of an abstract machine ..." C99 5.1.2.3.1

[andyturk]

Me? I'ld take "#define SECTOR_SIZE (512)" any day.... but that you never know, it might grow on me.

Well yeah, that works. One practical reason against macro constants is that they're unknown to your debugger, since they get stripped away before the compiler. Macros are also sloppy when it comes to strong typing.

Frequently, I'll use enums in an API when I want to make sure that an argument to a function/method has a limited range of values and enforce that at compile time. ints are, well, integers, and force you to check stuff at runtime (if at all).

Truth be told, I spend most of my time in C++ and depend heavily on compile-time type checking to keep me out of the weeds. Things like strongly type enums and 'const' (did I just hear a gasp from the back row?) flush a lot of problems out before I fire up the J-Link.

And my static constexpr function can beat up your #define expansion any day of the week. ;-)

The pre-processor is the part of the C language.

Is it really? The C standard is pretty specific about how expressions are evaluated. E.g., what something like "a+b" means when the types of the identifiers are specified. But when you don't know those types, the standard won't have much to say.

I've got a special rule in most of my makefiles that produces the preprocessed output only (i.e., no object code) specifically for tracking down goofy things that happen with macros:

Code: [Select]

$(BUILD)/%.E : %.c | $(BUILD)
@echo Compiling $(subst $(ABS_ROOT),,$(<))
@$(CC) $(CFLAGS) -E -c $< -o $(@)

I like the preprocessor for #include, #pragma once and X-macros, but constants and inline functions are better handled (IMO) by constants in the language itself and inline functions.

...

I'll confess that I've been abusing the preprocessor on a recent project though. Some of the code is automatically generated (CubeMX) and the generated main() conflicts with mine, causing the linker to complain.

But the preprocessor can get around this by changing function names from the outside. Another gnu makefile snippet:

Code: [Select]

$(OBJ)/$(BOARD)/cubemx/Src/main.o : CFLAGS += -Dmain=cubemx_generated_main

That defines "main" to be a macro that evaluates to some other name, but just for the compilation of that one specific file. It requires a target-specific variable definition in the Makefile, which I'm sure crosses a line.  But it's a lot easier than having to sed the output.

[legacy]

The C language is not concerned with the implementations. It is only concerned with the results:

Precisely another defect of the C language: are you really sure two implementations produce exactly the same results? In several circumstances I have experimented different behaviors with different compilers and pre-processors.

But the point was: the macro processor simply replaces patterns without being aware of the size, type and signed.

Too bad.

[Nusa]

The C language is not concerned with the implementations. It is only concerned with the results:

Precisely another defect of the C language: are you really sure two implementations produce exactly the same results? In several circumstances I have experimented different behaviors with different compilers and pre-processors.

But the point was: the macro processor simply replaces patterns without being aware of the size, type and signed.

Too bad.

Indeed. Over the years I've lost count of the number of annoying portability errors I've fixed simply by moving same-line // comments to their own line. Mostly in other peoples code. I learned not to same-line comment defines a long time ago, even if you can get away with it 99% of the time.

[NorthGuy]

Precisely another defect of the C language: are you really sure two implementations produce exactly the same results? In several circumstances I have experimented different behaviors with different compilers and pre-processors.

Of course, there could be bugs in implementations. It's true for every language or tool. How's that a defect of a language?

From my experience, bugs are relatively rare in C. If you stick to the standard and understand what you're doing, it is very likely to be portable.

But the point was: the macro processor simply replaces patterns without being aware of the size, type and signed.

That's right. It writes your program for you exactly as you said. Why should it worry about the types? Like text editor. It doesn't worry about types. Does this bother you?

[NorthGuy]

The pre-processor is the part of the C language.

Is it really? The C standard is pretty specific about how expressions are evaluated. E.g., what something like "a+b" means when the types of the identifiers are specified. But when you don't know those types, the standard won't have much to say.

The C standard is also very specific about how the pre-processor work. In fact, it is more specific about the pre-processor than it is about typed expressions.

[andyturk]

The C standard is also very specific about how the pre-processor work. In fact, it is more specific about the pre-processor than it is about typed expressions.

OK, so we can agree the preprocessor is both well defined and standardized. That doesn't mean it's a good idea to use macro substitutions for constants, although one certainly can.

Let's flip it around... What advantages does a macro offer over a proper C constant?