3 ms·

I'll shake my cane here. It's a mistake to add unnecessary features to the C preprocessor when we should be putting that sucker to bed already. The CPP was a ma

by kabdib 6y ago

I'll shake my cane here. It's a mistake to add unnecessary features to the C preprocessor when we should be putting that sucker to bed already. The CPP was a marginally bad idea 45+ years ago when it was invented, and it only hurt language tooling when C took off in the 80s and wasn't replaced by something better. I guess you can always write a pre-preprocessor to fix things up for an older preprocessor. But, ugh.

skissane 6y ago
I think it was unfortunate that the C preprocessor syntax is completely different from that of the C language itself. PL/I's preprocessor syntax is (approximately) a subset of the normal PL/I syntax (with a % sign in front to distinguish preprocessor instructions from code). I think that's a better approach. That said, there is so much C code in existence assuming the existing C preprocessor, it is more feasible to add new features to the existing one than replace it with something new and incompatible. I wish they'd add some better syntax for multi-line macros. So instead of: #define TRY(what) \ do { \ int r = (what); \ if (r != 0) \ return r; \ } while (0) you could write something like this: #macro TRY(what) do { int r = (what); if (r != 0) return r; } while (0) #endmacro Get rid of the backslashes (which are easy to screw up). It would also enable you to use #if conditionals inside the #macro block, so you could easily write conditional macros. Also, maybe instead of the do { ... } while (0) trick, #macro could automatically insert do { } while (0), maybe say if the #macro had a { on the same line: #macro TRY(what) { int r = (what); if (r != 0) return r; } #endmacro Some kind of looping support (e.g. #while) would also be great: #macro NULLS(count) # local i 0 # while (i < count) NULL, # define i i+1 # endwhile #endmacro In the above, #local is #define but local to the #macro block.
- foundry27 6y ago
  Looping is already totally doable, up to a finite maximum number of iterations. Local variables and the like can be simulated through suitably clever preprocessor definitions and logic, too. The syntax and trickery you need to take advantage of it is thoroughly, thoroughly unpleasant though. For anyone curious about the practicality of that sort of thing, A CPS macro continuation machine like https://github.com/rofl0r/order-pp/blob/master/inc/order/cm.h https://github.com/rofl0r/order-pp/blob/master/inc/order/cm.... would give you about 18 quintillion loop iterations if my math was right; double the length of that file and you’d have more loop iterations than atoms in the universe.
rcxdude 6y ago
I think it would have been much better to design an alternative with the same feature set (i.e. code generation through substitution), but better overall design in terms of hygiene and scoping, as opposed to what C++ has been trying to do by making ad-hoc replacements for some of the tasks you would want to use the preprocessor for, and then admonishing anyone who uses it because of limitations in the replacements. Macros are fundamentaly extremely useful, and the CPP is bad because it's a bad implementation of the concept (as well as leant on far too hard for importing interface definitions), not because the concept itself is bad.

by kabdib 6y ago

skissane 6y ago

I think it was unfortunate that the C preprocessor syntax is completely different from that of the C language itself. PL/I's preprocessor syntax is (approximately) a subset of the normal PL/I syntax (with a % sign in front to distinguish preprocessor instructions from code). I think that's a better approach. That said, there is so much C code in existence assuming the existing C preprocessor, it is more feasible to add new features to the existing one than replace it with something new and incompatible. I wish they'd add some better syntax for multi-line macros. So instead of: #define TRY(what) \ do { \ int r = (what); \ if (r != 0) \ return r; \ } while (0) you could write something like this: #macro TRY(what) do { int r = (what); if (r != 0) return r; } while (0) #endmacro Get rid of the backslashes (which are easy to screw up). It would also enable you to use #if conditionals inside the #macro block, so you could easily write conditional macros. Also, maybe instead of the do { ... } while (0) trick, #macro could automatically insert do { } while (0), maybe say if the #macro had a { on the same line: #macro TRY(what) { int r = (what); if (r != 0) return r; } #endmacro Some kind of looping support (e.g. #while) would also be great: #macro NULLS(count) # local i 0 # while (i < count) NULL, # define i i+1 # endwhile #endmacro In the above, #local is #define but local to the #macro block.

foundry27 6y ago
Looping is already totally doable, up to a finite maximum number of iterations. Local variables and the like can be simulated through suitably clever preprocessor definitions and logic, too. The syntax and trickery you need to take advantage of it is thoroughly, thoroughly unpleasant though. For anyone curious about the practicality of that sort of thing, A CPS macro continuation machine like https://github.com/rofl0r/order-pp/blob/master/inc/order/cm.h https://github.com/rofl0r/order-pp/blob/master/inc/order/cm.... would give you about 18 quintillion loop iterations if my math was right; double the length of that file and you’d have more loop iterations than atoms in the universe.

rcxdude 6y ago

I think it would have been much better to design an alternative with the same feature set (i.e. code generation through substitution), but better overall design in terms of hygiene and scoping, as opposed to what C++ has been trying to do by making ad-hoc replacements for some of the tasks you would want to use the preprocessor for, and then admonishing anyone who uses it because of limitations in the replacements. Macros are fundamentaly extremely useful, and the CPP is bad because it's a bad implementation of the concept (as well as leant on far too hard for importing interface definitions), not because the concept itself is bad.