Why is nanoprintf organized as a single header? #262
-
Hello, I found this repo and I'm interested in integrating it in to one of my embedded projects, but I'm confused by the organization of it. I'm used to defining functions in header (.h) files, and writing the rest of my code in source (.c) files. In this project, everything is in a single header file. Was it a deliberate decision to not use a .c source file? Is there an advantage to writing the code this way? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
There's a good write-up about the single-header approach here: https://github.com/nothings/stb?tab=readme-ov-file#why-single-file-headers The tl;dr is that with a single header file, there's no required build-system lingua franca, and if you want to, you can statically sandbox the nanoprintf implementation inside of a single .c file of your own, with all of the npf_ symbols staying completely private. I don't think the approach makes sense for larger projects, but being able to just grab and check in a single header file into your repo is pretty convenient! If you do like it split up into two separate files, go for it! I left a comment in the code around line 56, that's where you'd make the cut and either delete or define |
Beta Was this translation helpful? Give feedback.
There's a good write-up about the single-header approach here: https://github.com/nothings/stb?tab=readme-ov-file#why-single-file-headers
The tl;dr is that with a single header file, there's no required build-system lingua franca, and if you want to, you can statically sandbox the nanoprintf implementation inside of a single .c file of your own, with all of the npf_ symbols staying completely private. I don't think the approach makes sense for larger projects, but being able to just grab and check in a single header file into your repo is pretty convenient!
If you do like it split up into two separate files, go for it! I left a comment in the code around line 56, that's where you'd make t…