3 ms·

Neat, but why? Is it just the novelty that it can be done? I thought it was poor form to have a lot of code in headers. This seems like it'd be better served

• foota 7y ago
  I think the main reason is simplicity. No need to muck around with custom make files if you can just include the header and call it a day.
  • sigjuice 7y ago
    A makefile will most likely already have a list of .c files. Why not add one more .c file to that list and call that a day?
• astrodust 7y ago
  For tiny things like this I'd prefer a single header file over something that's a compiled dependency.
• rcfox 7y ago
  > I thought it was poor form to have a lot of code in headers. It is mostly because it makes it harder to reuse compiled objects when you make a change and rebuild. For a drop-in library that you're probably not editing, this shouldn't be an issue.
• downerending 7y ago
  I can see it either way, but for a tiny program this could be handy. For a larger program that already has multiple source files, it seems like it'd be better to keep it in a separate file (to make the git diffs easier to follow, for example). It would be better if it was namespace'd in some way, at least by using a common unusual prefix for all of the non-local symbols. It wouldn't be hard to clash with the chosen names.
• Chabs 7y ago
  It traditionally leads to bigger executables and longer compile times. With modern compilers, both of these are non-issues for "most" reasonably-sized projects.
• deleted 7y ago
  [deleted]