3 ms·

I think what OP did was taking it a bit far but xacros definitely have their place in C. Most notably they are extremely useful for instantiating hardware inter

I think what OP did was taking it a bit far but xacros definitely have their place in C. Most notably they are extremely useful for instantiating hardware interfaces that often come with large amounts of boilerplate. I've also found use in them in combination with `_Generic` for implementing generic containers/data structures. Of course I don't use these all the time by any means but if I'm going to be using a complex data structure I might as well just use an xacro to do a glorified copy-paste for the structs and accessors. It's all type safe, doesn't make the code any less readable IMHO, and it's surprisingly very debugger friendly. The xacros used for this are all together only about 10 lines of code but they've saved me countless hours of work/headache over the years and I've never once seen them blow up in a way that isn't immediately diagnosable and fixable. I understand that macros are by no means to be used everywhere but I do find that macros/xacros provide an incredible amount of utility when putting together "library" or "HAL" code where there's a well defined interface but the internals can largely be hidden from the user/developer. Of course I'd generally just prefer to use C++ but when that's not an option or would add undue friction, I find macros/xacros to be a useful tool for a developer.

veltas 5y ago
I don't see any mention of xacros in the article.
- jacoblambda 5y ago
  Ah I don't believe it does but they are normally bundled under the "complicated macros that add features or significantly change how C code is written" category which is what I thought you were referring to.
  - veltas 5y ago
    Using xacros to generate a lot of boring data or simplistic init code is definitely worth the potential confusion/complexity for the reader, and they will no doubt appreciate the reduced effort in maintaining it despite potentially having to come out of their C comfort zone a bit. I've used macros to add or change control structures myself. I will sometimes use a TRY macro that runs an expression and returns when its value indicates an error (which reduces line count significantly in some files), but there are almost no caveats with that one and you can look at the macro definition and understand it immediately. Most of us use ARRAY_LENGTH or DIM macro to get the length of a fully typed array, this is highly conventional so there's no confusion. But this article is adding tweaks to C control flow that really I could live without and are just about complicated enough to scare and waste the time of anyone stuck maintaining it, that's my concern. It's a real concern, based on my own experience and watching the many C programmers around me tackle fixing or upgrading such code. Macros that try to be "too smart" and try to simplify or make some control structure in C more elegant with hidden complexity and caveats under its preprocessor hood are harder to maintain, I don't think the 'nicer' code you get is worth the extra work maintaining it. It's probably applied with the least potential cost in a code base that will be written and maintained by only one person, but most professional C you need to assume will be maintained by other people as well as yourself. That's the angle I'm coming from.
    - jacoblambda 5y ago
      OK that makes sense. I think then that we are in agreement. Sorry for the misunderstanding.
      - veltas 5y ago
        No need to apologise, I just didn't understand your comment.

veltas 5y ago

I don't see any mention of xacros in the article.

jacoblambda 5y ago
Ah I don't believe it does but they are normally bundled under the "complicated macros that add features or significantly change how C code is written" category which is what I thought you were referring to.
- veltas 5y ago
  Using xacros to generate a lot of boring data or simplistic init code is definitely worth the potential confusion/complexity for the reader, and they will no doubt appreciate the reduced effort in maintaining it despite potentially having to come out of their C comfort zone a bit. I've used macros to add or change control structures myself. I will sometimes use a TRY macro that runs an expression and returns when its value indicates an error (which reduces line count significantly in some files), but there are almost no caveats with that one and you can look at the macro definition and understand it immediately. Most of us use ARRAY_LENGTH or DIM macro to get the length of a fully typed array, this is highly conventional so there's no confusion. But this article is adding tweaks to C control flow that really I could live without and are just about complicated enough to scare and waste the time of anyone stuck maintaining it, that's my concern. It's a real concern, based on my own experience and watching the many C programmers around me tackle fixing or upgrading such code. Macros that try to be "too smart" and try to simplify or make some control structure in C more elegant with hidden complexity and caveats under its preprocessor hood are harder to maintain, I don't think the 'nicer' code you get is worth the extra work maintaining it. It's probably applied with the least potential cost in a code base that will be written and maintained by only one person, but most professional C you need to assume will be maintained by other people as well as yourself. That's the angle I'm coming from.
  - jacoblambda 5y ago
    OK that makes sense. I think then that we are in agreement. Sorry for the misunderstanding.
    - veltas 5y ago
      No need to apologise, I just didn't understand your comment.