The point on exceptions I think is also misleading. Compilers typically make throwing an exception the expensive part, and the happy path inexpensive (not more expensive than a branch checking for errors, which should be the baseline for comparison, not an implementation with zero error checking.) So to say that they are "expensive" doesn't really make a useful argument.
And there are more things that could be done in this camp, like proposing a set of compiler flags, and a linter to enforce the subset you are subscribing to. Unfortunately the post offers none of that.
> <deque>: Needs a major performance overhaul", acknowledging that the standard's mandated block size is too small and the design needs to be rebuilt at the next ABI break
Except of course the standard does not mandate a block size. That's purely msvc picking a wrong block size and being stuck with it.
> There are many more things to avoid than just iostream.
But even "avoiding iostream" is stupid. The author presumably really means "avoid operator>> and operator<< for I/O". Even using type-safe printf-like stuff ultimately still sits on top of iostream.
If you want to see it where? If you want a string you've got a string. If you want to write text to something resembling file I/O (e.g. stdout) then std::print and std::println are what you need instead of std::format
Stroustrup's I/O Streams is a weird dead-end C++ technology. Bjarne is probably never going to get over it, but everybody else should forget about it ASAP.
Worth pointing out that the iostreams library is the work of many hands, so Stroustrup is not solely to blame. I just found this old SO question which I answered many years ago (I am anon/Neil) which addresses this:
I'm not wrong. It's been removed elsewhere for being LLM generated. This discussion has already been had multiple times.
The author used Claude to generate it and instructed it to intentionally insert mistakes. They had comments posted on Reddit that discussed doing this and their account is a slew of AI generated responses. The short responses where it appears they didn't use AI don't reflect the behaviour you'd expect from somebody that claims to have over 30 years of experience in HFT but rather point toward them being a teenager or somebody rather immature. They also make a number of wild claims that when put together, are unlikely to be true.
Sorry if you can't recognise it for what it is and shame on you if it's your website, given that you've previously submitted content from there.
It's a tiny website with low value AI generated content and a very quick look revealed that you've linked to multiple articles from there. It's a fair enough observation that you might be affiliated. I don't think you are, though, hence the 'if'.
There are many more things to avoid than just iostream. HFT university has a good recap: https://hftuniversity.com/post/the-c-standard-library-has-be...
The point on exceptions I think is also misleading. Compilers typically make throwing an exception the expensive part, and the happy path inexpensive (not more expensive than a branch checking for errors, which should be the baseline for comparison, not an implementation with zero error checking.) So to say that they are "expensive" doesn't really make a useful argument.
And there are more things that could be done in this camp, like proposing a set of compiler flags, and a linter to enforce the subset you are subscribing to. Unfortunately the post offers none of that.