A C Macro that reference another macro

[SiliconWizard]

Well yeah, as often. The discussion drifted off about macros in general, but the OP went away and never answered our questions. But this is usual and nothing special.

[Kalvin]

If you cannot or do not want to use use x-macro wizardry, why don't you just create a simple utility which will generate the required C source code into a file, which you can include into your project. Just add the code generator as a part of your project's makefile, and the tool will regenerate the source code as needed if the utility or its input data file changes.

[Siwastaja]

Always try with macro wizardry, though.

Code generation is sometimes the unavoidable evil, but using external code generation when the actual language itself supports what is needed directly is just nuts.

In order of preference, try to first make things work without macros, i.e., normal C code. Now if this is impossible, inefficient or results in unreadable code (or copy-pasting, which is evil), use C preprocessor and its features and tricks to achieve what is needed. If this is impossible as well (or unreadable), then as the last resort, go for external code generation.

[golden_labels]

One should use the right tool for the job. C preprocessor is very primitive, tricky and using it quickly becomes more trouble than help. Being a language, that is completely separate from C proper, makes it even worse.

If you need simple token replacement or concatenation, it’s perfectly fine. But the moment you move towards decision making and calculations, it turns into a horror. While it is Turing-complete,⁽¹⁾ it is unreadable, requires using an inconvenient input format, can’t be easily debugged and error messages are gibberish.

Using a separate tool is much more convenient and, by all means, better. Even unnatural tools like m4 are considerably better at most tasks you could imagine. Not to mention simply using any popular scripting language that appeared in the past 20 years. Python or Perl are easily obtainable, are open, are free, likely already present on developer’s computer anyway. Something that takes 500 unreadable of lines of C preprocessor, heavily dealing on already pre-generated Boost.Preprocessor, can be cleanly expressed in either of those in just few lines.
____
⁽¹⁾ Subject to resources limitation, which in the case of preprocessor metaprogramming must be manually pre-defined.

[Nominal Animal]

Using a separate tool is much more convenient and, by all means, better.

I've used awk to generate precomputed (trigonometric etc. fixed point) tables used on architectures without hardware floating point support, as simple header files.  I do recommend splitting the generated part into a separate file you simply #include in the actual header or source file, instead of using some sort of templates (as certain development environments do), and use an easily recognized file name or extension for it.  Keep It Simple, and consider the human who happens to have to maintain the code a year or two from now: it often is yourself, and you'll be glad then of the consideration.  I am, almost constantly.

I've even used a pre-build C program to generate (and verify perfectness) of a hash table of known keywords/tokens, to speed up configuration file parsing.  Essentially, it uses the given hash function, the list of tokens, and generates the minimum size hash table that has no collisions, brute-forcing it, and emits the result as a nice C header file.  (In this case, it is important to check that the host and target architectures use the same hash algorithm and hash size.  If the hash algorithm works on a byte-by-byte basis, byte order does not matter.)

I've also used objcopy to generate ELF object files directly from binary data, without processing it through the compiler. I usually use a scriptlet that generates a suitable header file describing the object too (including the size, which otherwise would be a link time constant, not a compile time constant).

ELF-based toolchains have a lot of useful tricks you can do to make maintenance easier. Using sections to collect entries in different files into a single contiguous array is one of my favourites: the linker does all the hard work for you, and you only need to make sure that the size of the entries is a multiple of the alignment.  You can even make it an sort-of-list of variable-length entries, if each entry begins with its size.  Very useful for compile-time extensions, menus, and such on embedded environments, as all that data can be put into ROM/Flash, without having to run some "registration" functions at run time: if the facility is linked to the final binary, then the related menu entries are too.  Simples.

There are a lot of useful tools, from macros to data/code generation to pure binary tools, but without additional information on the task at hand, we're just discussing the various options and possible scenarios.

@jealcuna, why did you leave us hanging? 

[SiliconWizard]

And yes, as always, it all depends. Sometimes code generators are cool. Sometimes they are just added "noise". Depends on use case.

The C preprocessor is not bad at all IMO. It has the merits of being well known, standard, and doing what we ask it to do. Oh I've tried alternatives in the past too. I too tried using M4. This looked promising at first, but I quickly stepped back. The experience was a lot more painful than expected, with the added issue that having your code maintained by other people would of course be more difficult.

I mostly use code generators - as Nominal mentioned - to generate precomputed tables (including images). Not as meta-programming layer.