4 ms·

> If header-only libraries start requiring you to use build-time tests, you lose the main reason to use them in the first place. Header-only libraries don't re

> If header-only libraries start requiring you to use build-time tests, you lose the main reason to use them in the first place. Header-only libraries don't really work as advertised anyway. The need for various parts of a codebase (including copy-pasted third party headers) to coordinate on preprocessor settings is a good example of this. Header only is great for casual research but pretty much immediately require extra work on the part of consumers. The C community would do well to acknowledge that build and packaging system convergence is overdue. Messing around with header-only and preprocessor tricks is leaving the community in an awkward cul-de-sac.

acuozzo 5y ago
> The C community would do well to acknowledge that build and packaging system convergence is overdue. This would require an enormous amount of planning and forward thinking to pull off successfully. I mean, hell, there isn't even a way to trust most libraries. So many of them are littered with type punning that e.g. the moment you move them off of x86 you're greeted with bus errors in stateless functions. Undefined behavior everywhere. And then you have the "Oh, sizeof (long) will always be the same as sizeof (void *) and I can definitely do this cast!" libraries from 1999. Those are fun. Even better are the "CHAR_BIT==8 everywhere in the world!" libraries that somehow forget to #error when that's not the case, so you have to manually review each and every assumption in each dependency before building for that fancy DSP. It's a mess. Even with the recent popularity of ARM, many C programmers either forget platforms other than GNU/Linux on x86 exist or forget to document what they're targeting.
- mlyle 5y ago
  > And then you have the "Oh, sizeof (long) will always be the same as sizeof (void *) and I can definitely do this cast!" libraries from 1999. Those are fun. Just out of curiosity-- where does this break down in common use? I know of some microcontrollers where e.g. long is 32 and pointers are 16... but most things really are ILP32 or LP64. P.S. Long, long ago you wrote you found Mel Kaye, and I'm always curious about the actual story.

acuozzo 5y ago

> The C community would do well to acknowledge that build and packaging system convergence is overdue. This would require an enormous amount of planning and forward thinking to pull off successfully. I mean, hell, there isn't even a way to trust most libraries. So many of them are littered with type punning that e.g. the moment you move them off of x86 you're greeted with bus errors in stateless functions. Undefined behavior everywhere. And then you have the "Oh, sizeof (long) will always be the same as sizeof (void *) and I can definitely do this cast!" libraries from 1999. Those are fun. Even better are the "CHAR_BIT==8 everywhere in the world!" libraries that somehow forget to #error when that's not the case, so you have to manually review each and every assumption in each dependency before building for that fancy DSP. It's a mess. Even with the recent popularity of ARM, many C programmers either forget platforms other than GNU/Linux on x86 exist or forget to document what they're targeting.

mlyle 5y ago
> And then you have the "Oh, sizeof (long) will always be the same as sizeof (void *) and I can definitely do this cast!" libraries from 1999. Those are fun. Just out of curiosity-- where does this break down in common use? I know of some microcontrollers where e.g. long is 32 and pointers are 16... but most things really are ILP32 or LP64. P.S. Long, long ago you wrote you found Mel Kaye, and I'm always curious about the actual story.