A Defer Mechanism for C

Re:A Defer Mechanism for C by dooglius on Monday December 14, 2020 @12:13PM (#25420053)

Some commenters are claiming this issue can be worked around by using by-reference capture, but the following code still requires dynamic allocation:

  void reverse_bitstream(void * read_ctx, void * write_ctx) {
    guard {
      while(has_more_bits(read_ctx)) {
        int b = read_bit(read_ctx);
        if     (b == 0) defer write_bit(write_ctx, 0);
        else if(b == 1) defer write_bit(write_ctx, 1);
      }
    }
  }

[ Parent | on HN ]

Re:A Defer Mechanism for C by mskslal on Monday December 14, 2020 @12:23PM (#25420225)

An example like that is exactly why, in its current form, it's a bad idea. It's too high level. On the surface it seems like it makes code more consise and elegant, but in reality it just pushes the "ugly" implementation details and allocations onto the compiler. When you start writing code that's phrased in terms of high-level compiler features, rather than in terms of what the computer needs to do, then you're no longer writing C.

[ Parent | on HN ]