All software is layers after layers after layers. If you look at a video of cat dropping things from the table on Youtube, and count all levels of layers (all functions and ifs and elses) from the upmost level to the pixel drawing in the GPU HDL, you have possibly thousands. They are just... encapsulated.
Four layers in itself isn't the problem. They should have done some form of encapsulation; utilize makefiles and separate .c files, or maybe just used #include better, or so on. You can totally do abstraction in preprocessor, and compilers can follow it in error messages etc. ("in macro XXX, included from file YYY...")
And indentation helps for a few levels. But arguably, 4 levels of just preprocessor indentations is pushing it. Code ending up far right reveals it is too much. Solution is not to remove indentation.
All software is layers after layers after layers. If you look at a video of cat dropping things from the table on Youtube, and count all levels of layers (all functions and ifs and elses) from the upmost level to the pixel drawing in the GPU HDL, you have possibly thousands. They are just... encapsulated.
So you can compare *layers of code* (under control) with *layers of macro* (out of control, just text-replaced with text).
I don't understand the difference you talk about. Why macros are "outside of control"? What does this "control" even mean?
Why can't you testbench the macros with test vectors?
Compiler can decide to inline any function (even non-static!) without asking you, at all, for optimization, acting exactly like it was a macro.
Sure, preprocessor is kind of its own language, and thus has its own footguns.
Like tabs vs. spaces and brace style, macros are yet another of those hot topics.
Some people having a problem with multi-level macros appears to be a common thing - I've heard that quite a few times.
I do not quite get it either myself. As you said, like with general code, it's just a matter of writing readable and correct stuff.
The benefit of writing multi-level macros is the same as using macros in general: avoiding to duplicate code by hand, and making some modifications much easier (when there is only ONE place where changes need to be made.)
As Siwastaja said, if you're really unsure of macros - just write a set of tests for them. It's unusual (I've never done that myself and never seen it done directly), but it's definitely doable. Just write a series of tests invoking macros and the expected output, then invoke the preprocessor separately (all C compilers I've ever used could do this), and compare. It can be fully automated.
There are well known "pitfalls" of macros due to the fact they are just text substitution. The first class of them appears when macro parameters are not all parenthesized. Just put parentheses around all parameters in macro expressions, and this issue disappears immediately. The other one, of course, is calling a macro with parameters that have side-effects, if said parameters are used more than once in a given macro definition. To mitigate this one, you can either make it a rule never to call a macro with parameters that have side-effects, or never write a macro that substitutes any of its parameters more than once. Done.
The benefit of writing multi-level macros is the same as using macros in general: avoiding to duplicate code by hand, and making some modifications much easier (when there is only ONE place where changes need to be made.)
Um like what? Qualcom's code? Denx's code? Atheros's code? Yes, macro avoid them to duplicate code by hand, but when you have to fix their code you cry up with dozen of order on Amazon ...
What? Which orders? baskets of migraine pills, family packages
just write a set of tests for them. It's unusual (I've never done that myself and never seen it done directly), but it's definitely doable
Which brings us to what I wrote a page ago:
I know I can write a series of tests, but guess what? Who do you think has usually to write those tests because other people simply don't care?
Dude, when you have to fix a code like that and you're not getting paid for it, you don't really like wasting days and days on it because you don't understand what layers of macro do.
I do not quite get it either myself. As you said, like with general code, it's just a matter of writing readable and correct stuff.
No, it's not a question of elegant code, but rather of having tools that understand and process the code so that you can do your job without constant headaches.
I think by today hardly anyone develop commercial systems using Pascal. By commercial systems I mean anything used in a product or business. So, comparing Pascal and C is rather academic now.
Not ISO Standard Pascal certainly, but Pascal with numerous extensions lives on in the commercial world in the form of Delphi:
https://www.embarcadero.com/products/delphi