This happens to ... a friend of mine.
Now, granted, too many people / organisations / whole fucking countries aren't even learning from their own experiences, but you should really strive to learn from others too.
-- Douglas Adams, Last Chance to See
:-)
But I take your point.
However, responding here since you did, I think you missed the whole point of that sub-thread. People aren't telling you that Bjarne's terrible I/O streams functionality is great so you should use that. They're praising the much more normal looking std::format and related features which have been adopted from fmt.
As a result assessing Bjarne's I/O streams and discovering that they're terrible is not a meaningful reaction to that praise. We know Bjarne's feature is bad, we're talking about a different, much better, feature.
Well, std::format is what you actually told me I was a fool and a noob for refusing to use under the pretense of being pragmatic. ("you are deliberately choosing to use poor tools and calling this "pragmatism" because it sounds better than admitting you're bad at this and you don't even want to improve")
So I've finally put in the work and made std::format run on MSVC because that's the only compiler where std::format is available for me (gcc-12 and clang-14 don't include it on my Debian VM).
And guess what, simple file with main() and std::format("Hello {}\n", 42) + fwrite() takes 1.4 seconds to compile there (no linking, no optimizations) compared to 0.16s for compiling a cpp file with the equivalent snprintf/fwrite call.
0.16s is still much but MSVC takes 0.12s for compiling "return 0". Subtracting that, it's a somewhat reasonable overhead of 0.04s for including + using stdio.h / snprintf. And 1.28s, so literally 32x that amount, and realistically a nerve wrecking time to wait for a single file to compile, for the std::format version.
I'm not sure how to take you seriously anymore. It's hard to imagine you've actually used this yourself, because paying more than a second to compile a single print statement is not OK. I wish people like you would just be a little less loud and more considerate when judging people that are trying to actually get something done.
The code under test:
#include <format>
#include <string>
#include <stdio.h>
int main()
{
std::string x = std::format("Hello {}\n", 42);
fwrite(x.data(), 1, x.size(), stdout);
return 0;
}
$ cl /version Microsoft (R) C/C++ Optimizing Compiler Version 19.35.32216.1 for x64
Here is a godbolt where gcc-13 with fmtlib setup (as a library) is tested against stdio.h printf(). It's 600-1200ms for std::print(...) vs 60-120ms for printf(...) and just a few ms less for "return 0". (timings are highly variable on godbolt). Again, an overhead of probably some 20x-100x compared to stdio.h printf when we subtract the time for compiling "return 0".I should expect most people have more than one. Have you ever seen a benchmark which tried just calling some library feature once and then pronounced it slow? Like, hey, your new hash table is slow, I called insert on it with one value and that took ages / How about the next time? / What do you mean next time, it's slow, I'm never using it again.
Perhaps this all points to a process issue, that your development process is... let's say unusual and that's driven you to make some perverse trade offs because you aren't able to imagine a way to do what you do with the technology everybody else is using. Maybe they're not the crazy ones ?
https://twitter.com/magdraws/status/1551612747569299458
The good news, though probably in the distant future for you, is that C++ standard library modularisation should dramatically speed up compilation since the compiler won't need to laboriously discover all the facts about foo.h over, and over, and over again as it is mentioned in each place it's used.
But you're right, I don't use any of this stuff in anger, I write Rust. I admire fmt because I think it's a remarkable achievement to have a type checked formatter as a library function.
Oh, I have many seconds, and I'm already spending many of them, to the point that I'm not willing to just give them out for free. In a project with dozens or hundreds of files I'm not willing to introduce a central dependency that slow down each of them by one additional second.
> The good news, though probably in the distant future for you, is that C++ standard library modularisation should dramatically speed up compilation since the compiler won't need to laboriously discover all the facts about foo.h
I'll believe when I see it. Have you tested it? Currently, we can't use modules at work since we're not on the newest compiler.
"The good thing about making mistakes, is that you get to know which mistakes are worth making."