Comment by einpoklum
1 day ago
> You edit the source code. That's the customisation?
I meant, customization where you don't have to write the customized code yourself, just choose some build options, or at most set preprocessor variables.
> First, it is customary etiquette to indicate when linking your own code/work.
You're right, although I was only linking to the table of CMake options. And it's only partially my code, since I'm the maintainer rather than the original author
> You're bringing in your own printf. Just adapt it to your own I/O backend, like libc has FILE.
One can always do that, but - with the output callback - you can bring in an already-compiled object, which is sometimes convenient.
> If you use your own printf, you probably need a bunch of other custom stuff anyway.
My personal use case (and the reason I adopted the library) was printf deficiencies in CUDA GPU kernels. And - I really needed nothing other than printf functions. Other people just use sprintf to format output of their mostly, or wholly, self-contained functions which write output to buffers and such. Different strokes for different folks etc.
But - I will definitely check out the link.
> Second, that is not a POSIX compatible printf, it lacks support for '%n$' (which is used primarily for localisation).*
That is true. But C99 printf and C++ printf do not support that either. ATM, the aim is completing C99 printf support (when I actually work on the library, which is not that often). So, my priority would be FP denormals and binary FP (with "%a"), before other things.
> * Arguably can make sense to omit for tiny embedded platforms - but then why is there FP support?*
It's there because people wanted it / needed it; and so far, there's not been any demand for numbered position specification.
> I meant, customization where you don't have to write the customized code yourself, just choose some build options, or at most set preprocessor variables.
Honestly, if you're shying away from customising an 1-2kloc piece of code, you probably shouldn't be using a custom printf().
Case in point: function pointers are either costly or even plain unsupported on GPU architectures. I would speculate that you aren't using the callbacks there?
> Honestly, if you're shying away from customising an 1-2kloc piece of code, you probably shouldn't be using a custom printf().
Well, it was good enough for the arduino SDK to adopt: https://github.com/embeddedartistry/arduino-printf
> * function pointers are either costly or even plain unsupported on GPU architectures.*
When you printf() from a GPU kernel, your performance is shot anyway, so performance is not a consideration. And - function pointers work, as long as they all get resolved before runtime, and you don't try to cross CPU <-> GPU boundaries.
> > Honestly, if you're shying away from customising an 1-2kloc piece of code, you probably shouldn't be using a custom printf().
> Well, it was good enough for the arduino SDK to adopt: https://github.com/embeddedartistry/arduino-printf
Well, they didn't shy away from customizing it quite a bit ;)
To be clear I was trying to say it doesn't make too much sense to try to package this as an independent "easy to use" "library" with a handful of build options. Not that it's somehow not "good enough".
Put another way: a situation where you need/want a custom printf is probably a situation where a package like this doesn't exactly help you anyway and you'll need to muck with it regardless. But the code can be used. Which is exactly what the repo you linked did.