3 ms·

I never wanted to argue as much. I'm certainly not saying macros solve all the world's problems. Far from it, and as I said from the beginning, you need to use

I never wanted to argue as much. I'm certainly not saying macros solve all the world's problems. Far from it, and as I said from the beginning, you need to use them carefully. Here are examples of my typical uses: #define LENGTH(a) ((int) (sizeof (a) / sizeof (a)[0])) #define SORT(a, n, cmp) sort_array((a), (n), sizeof *(a), (cmp)) #define CLEAR(x) clear_mem(&(x), sizeof (x)) #define BUF_INIT(buf, alloc) \ _buf_init((void**)(buf), (alloc), sizeof **(buf), __FILE__, __LINE__); #define BUF_EXIT(buf, alloc) \ _buf_exit((void**)(buf), (alloc), sizeof **(buf), __FILE__, __LINE__); #define BUF_RESERVE(buf, alloc, cnt) \ _buf_reserve((void**)(buf), (alloc), (cnt), sizeof **(buf), 0, \ __FILE__, __LINE__); #define RESIZE_GLOBAL_BUFFER(bufname, nelems) \ _resize_global_buffer(BUFFER_##bufname, (nelems), 0) #define MSG(lvl, fmt, ...) _msg(__FILE__, __LINE__, (lvl), (fmt), ##__VA_ARGS__) #define FATAL(fmt, ...) _fatal(__FILE__, __LINE__, (fmt), ##__VA_ARGS__) #define UNHANDLED_CASE() FATAL("Unhandled case!\n"); #define ABORT() _abort() #define DEBUG(...) do { \ if (doDebug) \ _msg(__FILE__, __LINE__, "DEBUG", __VA_ARGS__); \ } while (0) And a clever one, saving a lot of typing (which many will argue only fixes a problem of C itself. But still). #ifdef DATA_IMPL #define DATA #else #define DATA extern #endif DATA char *lexbuf; DATA char *strbuf; DATA struct StringInfo *stringInfo; ... None of these is a maintenance burden, and each makes my life significantly easier. I don't believe there's a different scheme that is a better fit here.

joshuamorton 8y ago
Sure, but all of those solve problems that only really exist in C. If you're arguing that C, as it currently exists, needs text-macros, then maybe. But most of those macros are just dealing with flaws in C (lack of compile-time array-size tracking, no logging built in, etc.). In many languages, those macros aren't things you'd ever need to do. You're just being forced to make up for a flaw in the platform.
- zzo38computer 8y ago
  I disagree. If it isn't a macro then you cannot write your own kind of macro instead. Those things aren't really flaws in C (although there still are flaws in C, such as that macro expansions cannot include preprocessor directives). You need all of the kind of macro.
  - joshuamorton 8y ago
    >If it isn't a macro then you cannot write your own kind of macro instead I'm not sure what you mean here. ast-macros can still wrap ast-macros. And yes, I'd absolutely claim that not tracking array size at compile time is a flaw in C (rust fixes this, you can pass `&[int]` to a function (a reference to a compile-time-fixed-size array) and call `.len()` on the argument. This has no runtime cost in either space or speed). In the same way that I talk about cognitive overhead above, the requirement that a user manually pass around compile time information is dumb. Note that in C this wouldn't have prevented you from down-casting an array to a pointer, its just that the language wouldn't have forced this on you at every function boundary. The only reason C didn't do this is because the implementation was costly to the authors. It doesn't have any negative impacts to the end user (well, there's an argument to be made that there was a cost to the end user at the time, but I'm not sure how much I believe that).
    - zzo38computer 8y ago
      >I'm not sure what you mean here. ast-macros can still wrap ast-macros. Yes, although sometimes text macros are useful, but ast-macros are generally much better yes. >In the same way that I talk about cognitive overhead above, the requirement that a user manually pass around compile time information is dumb. If the macro facility is sufficient, it would be implemented by the use of a macro; you do not need to then manually write it during each time. In C, you can use sizeof. Also sometimes you want to pass the array with a smaller length than its actual length (possibly at an offset, too).
      - iopq 8y ago
        Rust tracks this use case, as you can slice the array smaller and it will track that it was sliced off further. No need to remember this kind of thing.
        deleted 8y ago
        [deleted]
    - 8y ago

joshuamorton 8y ago

Sure, but all of those solve problems that only really exist in C. If you're arguing that C, as it currently exists, needs text-macros, then maybe. But most of those macros are just dealing with flaws in C (lack of compile-time array-size tracking, no logging built in, etc.). In many languages, those macros aren't things you'd ever need to do. You're just being forced to make up for a flaw in the platform.

zzo38computer 8y ago
I disagree. If it isn't a macro then you cannot write your own kind of macro instead. Those things aren't really flaws in C (although there still are flaws in C, such as that macro expansions cannot include preprocessor directives). You need all of the kind of macro.
- joshuamorton 8y ago
  >If it isn't a macro then you cannot write your own kind of macro instead I'm not sure what you mean here. ast-macros can still wrap ast-macros. And yes, I'd absolutely claim that not tracking array size at compile time is a flaw in C (rust fixes this, you can pass `&[int]` to a function (a reference to a compile-time-fixed-size array) and call `.len()` on the argument. This has no runtime cost in either space or speed). In the same way that I talk about cognitive overhead above, the requirement that a user manually pass around compile time information is dumb. Note that in C this wouldn't have prevented you from down-casting an array to a pointer, its just that the language wouldn't have forced this on you at every function boundary. The only reason C didn't do this is because the implementation was costly to the authors. It doesn't have any negative impacts to the end user (well, there's an argument to be made that there was a cost to the end user at the time, but I'm not sure how much I believe that).
  - zzo38computer 8y ago
    >I'm not sure what you mean here. ast-macros can still wrap ast-macros. Yes, although sometimes text macros are useful, but ast-macros are generally much better yes. >In the same way that I talk about cognitive overhead above, the requirement that a user manually pass around compile time information is dumb. If the macro facility is sufficient, it would be implemented by the use of a macro; you do not need to then manually write it during each time. In C, you can use sizeof. Also sometimes you want to pass the array with a smaller length than its actual length (possibly at an offset, too).
    - iopq 8y ago
      Rust tracks this use case, as you can slice the array smaller and it will track that it was sliced off further. No need to remember this kind of thing.
      - deleted 8y ago
        [deleted]
  - 8y ago