Clearly yes.
BTW, I don't see a benefit to use a non-owning String_Buffer over std::string (or std::string_view) in this context.
kevin_thibedeau 4 hours ago [-]
The subtext is a resource constrained system where std::format is considered too heavyweight. In that scenario, explicit non-automatic memory management is a benefit. It could still leverage std::string_view and be agnostic on the topic.
If you're willing to use one measly little macro - solely to smuggle the format string in a constexpr manner - instead of insisting on using templates everywhere, you can use a printf wrapper with essentially 0 compile-time overhead. And the only runtime overhead is if you have to copy a `string_view` back into a `string` to add the `NUL`-terminator.
You do still need templates for the arguments (unless you're willing to resort to nasty preprocessor hackery, which would be needed if doing this in C - hmm, are the lifetime-of-temporary rules different too?), but it's pretty easy to just do:
where `to_owning_primitive` is the ADL'ed function you implement for every type you want to print, and `to_borrowed_primitive` probably only needs to be implemented for each string type (though I did find it also useful for wrapped integers of unknown size/rank, such as `time_t`).
secondcoming 1 hours ago [-]
Nice. I think most people have tried doing something like this in C++ at some point.
One issue that I had is that printing floating-point values really needs the ability for the user to specify the precision and format. It's actually absurd that `std::to_string(double)` does not allow this.
Also, I believe `std::to_chars(double)` uses a fast algorithm and allows writing directly into a buffer.
worstenbrood 4 hours ago [-]
Love the method name uhm
bool next_hole
vjvjvjvjghv 3 hours ago [-]
I much prefer string interpolation like
$"i={i}"
cppisnice 4 hours ago [-]
How many CVEs?
speed_spread 3 hours ago [-]
Yes, true. But the probability of finding new CVEs from any 65 lines of non-obfuscated code diminishes rapidly. In many situations I'd rather use a short minimal fresh lib that I can review as if it was mine than a mature but overly feature-loaded one that may still have any number of pending gotchas in dark corners.
prerok 1 hours ago [-]
I must admit I was very much against the practice of NIH syndrome, but if it's that short I would prefer to write my own version instead of adding a dependency.
In this day and age who knows when a dependency is hijacked :(
speed_spread 24 minutes ago [-]
At 65 lines, if the license is right, you can just copy it like you would with a StackOverflow answer. In these situations I leave a comment on top saying where the code came from so it can be revisited later.
You do still need templates for the arguments (unless you're willing to resort to nasty preprocessor hackery, which would be needed if doing this in C - hmm, are the lifetime-of-temporary rules different too?), but it's pretty easy to just do:
where `to_owning_primitive` is the ADL'ed function you implement for every type you want to print, and `to_borrowed_primitive` probably only needs to be implemented for each string type (though I did find it also useful for wrapped integers of unknown size/rank, such as `time_t`).One issue that I had is that printing floating-point values really needs the ability for the user to specify the precision and format. It's actually absurd that `std::to_string(double)` does not allow this.
Also, I believe `std::to_chars(double)` uses a fast algorithm and allows writing directly into a buffer.
$"i={i}"
In this day and age who knows when a dependency is hijacked :(