4 ms·

Header only libraries are great, and these little gems floating around are super easy to use, until you hit an unsupported (by them) feature, or something that

by malkia 3y ago

Header only libraries are great, and these little gems floating around are super easy to use, until you hit an unsupported (by them) feature, or something that now you have to do (like for year you've been using it for reading, but now you need to write the file, or interleave it, or whatnot). And then you realize you need the official lib - libpng, etc. E.g. it's not so simple.

kibibu 3y ago
Well, yeah. Unless things have changed, the stb image library is explicitly not for parsing arbitrary image files. > Primarily of interest to game developers and other people who can avoid problematic images and only need the trivial interface
edflsafoiewq 3y ago
The same is true for any lib. There is no guarantee even the largest lib will have everything you ever need. That's where new code comes from.
- malkia 3y ago
  That's not true. There are several established and well supported libraries that actually work as expected. Then there are other, optimized versions of them. The elephant in the room is the missing common build system, so folks engage in what's EASIEST - include just a header and you are done. This is awesome for initial development, gives you wings, but once your software has been deployed over and over - that header only library starts to show it's weakness - because it's header-only there are certain limitations - especially around how to handle singletons, initialization, and few other critical things.... And then compilation. Some header-only libraries, realize that and simply asks the user to at least do this once somewhere: #define SOME_HEADER_ONLY_LIB_IMPL 1 #include <some_header_only_lib.h> and above gets code that needs to be compiled in exactly one compilation unit, and not multiple. This is actually not so bad, if it was considered more... but it gets hairy when you have library that needs to use that header only library, and now up the tree of deps the top-most program has to do the above, and then it gets super messy. Again, it's super easy, but not simple (long term). I've seen it happen with code that I work, I've also written tons of header-only libs - they are exciting!
sevnin 3y ago
That's exactly the point of the lib. It's easy to use for common use cases. If it saved you time at the beginning, saved you from build system nonsense, learning convoluted apis and other crap for a year. That's a big win.
pjmlp 3y ago
Thankfully, now with C++ modules, I can package them and don't bother with them being parsed all over the place.
smallstepforman 3y ago
There is stb_image_write.h, with the function stbi_write_png().

by malkia 3y ago

kibibu 3y ago

Well, yeah. Unless things have changed, the stb image library is explicitly not for parsing arbitrary image files. > Primarily of interest to game developers and other people who can avoid problematic images and only need the trivial interface

edflsafoiewq 3y ago

The same is true for any lib. There is no guarantee even the largest lib will have everything you ever need. That's where new code comes from.

malkia 3y ago
That's not true. There are several established and well supported libraries that actually work as expected. Then there are other, optimized versions of them. The elephant in the room is the missing common build system, so folks engage in what's EASIEST - include just a header and you are done. This is awesome for initial development, gives you wings, but once your software has been deployed over and over - that header only library starts to show it's weakness - because it's header-only there are certain limitations - especially around how to handle singletons, initialization, and few other critical things.... And then compilation. Some header-only libraries, realize that and simply asks the user to at least do this once somewhere: #define SOME_HEADER_ONLY_LIB_IMPL 1 #include <some_header_only_lib.h> and above gets code that needs to be compiled in exactly one compilation unit, and not multiple. This is actually not so bad, if it was considered more... but it gets hairy when you have library that needs to use that header only library, and now up the tree of deps the top-most program has to do the above, and then it gets super messy. Again, it's super easy, but not simple (long term). I've seen it happen with code that I work, I've also written tons of header-only libs - they are exciting!

sevnin 3y ago

That's exactly the point of the lib. It's easy to use for common use cases. If it saved you time at the beginning, saved you from build system nonsense, learning convoluted apis and other crap for a year. That's a big win.

pjmlp 3y ago

Thankfully, now with C++ modules, I can package them and don't bother with them being parsed all over the place.

smallstepforman 3y ago

There is stb_image_write.h, with the function stbi_write_png().