Oh, C3!

[Siwastaja]

everything that doesn't pre-process the source is better because it doesn't hide information

But isn't that one of the main features of functions? They hide lots of nitty gritty detail behind a simple name (and, of course, let you reuse code without repeating it, which is also what macros can do).

DiTBho means it hides information otherwise accessible to his own automated analysis tool. The options are obvious, either go through the hassle of making that analysis tool understand macros (thus nothing would be hidden), or ban the use of macros. DiTBho has clearly chosen the latter and it's understandable as it's less work for him.

For example, modern C compilers have "understood" preprocessor (I think by producing metadata from the preprocessing step and forwarding it to the compiler) and not just blindly do text replacement as a separate preprocessing step; they can produce good error messages. The same idea could be followed in DiTBho's "ICE".

[DiTBho]

Specifically, there are three kinds of code repetition:

• type-1, the repetition that can be avoided by using "functions"
• type-2, the repetition that can be avoided by using "trivial macros"
• type-3, the repetition that can be avoided by using "complex macros with loops/recursion"

Which brings to what experienced C/{ 89, 99} programmers feel as "tagged patterns of code repetition".
Which brings the question: to avoid it, can pure C benefit from meta-programming?
Which brings the final question: since there is no other mechanism in C/{ 89, 99}, can the C pre-processor-macro be *the right tool* for some decent meta-programming?

The answer is: NO.
Technically it can be done, but it's practically too error prone.

What you want here is a replacement of the pre-processor, something built-in the language that allows you to eliminate code repetition by using macro iteration and with the complete support for algebraic data types and interfaces.

Your goal is also to reduce boilerplate and the risk of a failure.

And about that, I want to make myself clear: you need it strictly this way and nothing more. C++ does more than is required, making it a dangerous template meta-programming monster.

[Siwastaja]

The right balance between "stupidly simple and thus dangerous" and "too elegant and thus dangerous" is very difficult to achieve. What sounds nice on a CS department coffee room easily gets out of hands.

One-man project is likely to go less catastrophically wrong than something designed for years by a committee, so I'm sure your-C has better generic programming ideology than C++ 

[PlainName]

- functions are not pre-processed but compiled

That's a backroom issue though. Kind of like driving a car and saying this one is trash because the engine is petrol rather than diesel. On a technical level it can make a difference, but if you're having to deal with that regularly I think something is wrong.

- macro does not check any Compile-Time Errors, Function checks Compile-Time Errors

Not sure I get what you're saying there: doesn't a macro error result in a compiler error?

[PlainName]

DiTBho means it hides information otherwise accessible to his own automated analysis tool. The options are obvious, either go through the hassle of making that analysis tool understand macros (thus nothing would be hidden), or ban the use of macros. DiTBho has clearly chosen the latter and it's understandable as it's less work for him.

Sure, nowt wrong with that. I would do the same if I was making the stuff he was. But I don't think it's legitimate to say something is bad everywhere with no redeeming features because of some personal thing no-one else will encounter. And it's the general that I thought we were talking about here.

[SiliconWizard]

DiTBho means it hides information otherwise accessible to his own automated analysis tool. The options are obvious, either go through the hassle of making that analysis tool understand macros (thus nothing would be hidden), or ban the use of macros. DiTBho has clearly chosen the latter and it's understandable as it's less work for him.

Sure, nowt wrong with that. I would do the same if I was making the stuff he was. But I don't think it's legitimate to say something is bad everywhere with no redeeming features because of some personal thing no-one else will encounter. And it's the general that I thought we were talking about here.

Agreed, but to be fair, that tends to be the attitude of *most* people having designed programming languages, with only a very few exceptions.

[SiliconWizard]

everything that doesn't pre-process the source is better because it doesn't hide information

But isn't that one of the main features of functions? They hide lots of nitty gritty detail behind a simple name (and, of course, let you reuse code without repeating it, which is also what macros can do).

DiTBho means it hides information otherwise accessible to his own automated analysis tool. The options are obvious, either go through the hassle of making that analysis tool understand macros (thus nothing would be hidden), or ban the use of macros. DiTBho has clearly chosen the latter and it's understandable as it's less work for him.

What it hides to what (or whom) is the question here.

To the programmer, macros "abstract" pieces of code, so in that regard they "hide" code, but in a similar way other language abstractions do, as PlainName suggested.

Now the reverse happens for static analysis tools and compilers (usually): the code they analyse is the preprocessed code, and in that regard, macros hide no code to these tools. It's the converse: in that context, macros hide... the macros themselves, not the code they generate, as it's preprocessed.

Sure some more elaborate tools can "understand" macros (instead of merely preprocessing them before analysing the code) so the analysis can link to the original macros, which can be handy to... "debug" macros. Otherwise, it may not be that useful, you usually have line numbers to look at the original source code in case.

I think the main concern people have with macros is that they find it hard to prove the correctness of the code generated by macros - in other words, the correctness of macros themselves.
I've personally never introduced bugs due to macros I've written, that I can remember of, but I may be an alien, who knows.

Now if you still want/need to validate your macros as the rest of your code, you'd do just as you do for the rest of your code. Write "unit tests" for your macros. It's not rocket science.

[PlainName]

I think the main concern people have with macros is ...

They can turn into a write-only language. Especially with heavy use of ##.

[Siwastaja]

I think the main concern people have with macros is ...

They can turn into a write-only language. Especially with heavy use of ##.

Ignoring DRY and copypasting is way way way worse than a difficult-to-read macro.

Copypaste / search-and-replace bugs happen and they happen a lot. Also difficult to notice for a human reader; in 9 places out of 10, correct type/variable is used, but in one spot... Compared to that, a hard-to-understand macro is much better. Maybe it's hard to read, but you need to read and understand that only once, and then it produces perfect automated copy-paste each time used.

# and ## magic is pretty essential in many types of projects (for example, many different message types in a message processor), because the only other options would be getting rid of most typechecking and writing everything around void* pointers and generic buffers; or copypasting and manually modifying code gazillion of times. Both much worse.

[PlainName]

I guess it depends. From a user perspective, this kind of thing can be tricky:

Code: [Select]

return _lv_obj_get_style##style_type (obj, part, LV_STYLE_##prop_name);
It defeats editor/IDE lookup tools to figure out what it means, so while it no doubt helps the original author (and a user not trying to debug it) it's a drag for anyone else. This is one of the decent uses - I've seen much, much more user-hostile stuff.

[Siwastaja]

Doesn't look too nice, but isn't the alternative copy-pasting and search/replace the whole function? Possibly tens of times? That's just disastrous. Generic programming is needed. In C, that's using preprocessor. In C++, either preprocessor or template system. Generic programming never looks as simple as non-generic, no matter how well designed the language is. It's still super useful.

[PlainName]

but isn't the alternative copy-pasting and search/replace the whole function?

No idea - I gave up trying to figure out what it all means

[SiliconWizard]

"Obvious" tips to help with macros.

First, document your macros as soon as they are non-trivial. Funnily enough, I've seen A LOT of code in which the C code itself was heavily commented, but macros, almost NEVER.

Then, as I suggested earlier, if you want to be sure of your macros (or someone else's) and you have doubts, just TEST them.

Just because they are macros doesn't mean they are out of scope for testing.

Testing is not difficult.
Write test files that include the macros you want to test (ideally your macros sit in header files so just include the corresponding header files), and a bunch of test cases. It doesn't have to be C code at all. Just a series of macro invocations. Write the expected output in separate files.

Run the preprocessor on these test files and compare the outputs with your expected outputs with diff. All this can be fully automated.

[PlainName]

I think the issue with stuff like ## is the levels of redirection. We can keep in mind up to 7 levels (if we're good - most people aren't) and a #define is already one level. So you can sit and work it out and even write test cases and know what it does, but then trying to apply that in realtime to what you're looking at is like speaking Spanish while reading Mandarin. And, as I note, the usual tools that let you find, say, a function definition and its associated comments, don't work with this type of macro so you can't easily find any comment either.

[cfbsoftware]

The problem is that it's a half-baked solution: outside of cryptic constructs like the Duff's device, using fallthrough in switch-case in C was mostly meant to emulate the possibility of having cases for multiple values instead of just one. That was much better addressed even in Pascal (if I remember it right) using ranges.

FTR, Standard Pascal has case label lists e.g.

case ch of
  'a', 'e', 'i', 'o', 'u': chtype := vowel;
...
...

This was extended in Modula-2 to include case label lists and subranges e.g.

CASE ch OF
  'a', 'e', 'i', 'o', 'u': type := vowel |
  '0'..'9': type := digit |
...
...