6 ms·

<iostreams> are currently a good example of pure product of the 199X/2000s when the hype about Object Oriented was around its peak. Almost everything related t

by adev_ 3y ago

<iostreams> are currently a good example of pure product of the 199X/2000s when the hype about Object Oriented was around its peak. Almost everything related to c++ iostreams has this code smell of OOP pushed too far: - Usage of runtime virtual dispatch with virtual calls when it was not necessary. Causing a negative unavoidable impact on performance. - Heavy usage of function overloading with the "<<" operator. Leading to pages long compilation errors when an overload fails. - Hidden states everywhere with the usage of state formatters and globals in the background. - Unnecessary complexity with std::locale which is almost entirely useless for proper internationalisation. - Bloat. Any statically compiled binary will inherit around ~100k of binary fat bloat when using iostream - Useless encapsulation with error reports done as abstracted bit flags. Which is absolutely horrendous when dealing with file I/O: It hides away the underlying error with no proper way to access it. - Deep class hierarchy making the entire thing looks like spaghetti. - Useless abstraction with stringstream that hides the underlying buffer away, making it close to unusable on embedded safety critical systems where memory allocations are forbidden. All of that made <iostreams> aged pretty badly, and for good reasons. Fortunately there is an incoming way out of that with work of Victor Zverovich on std::format and libfmt [1]. [1]: https://github.com/fmtlib/fmt https://github.com/fmtlib/fmt

shiroiuma 3y ago
>Fortunately there is an incoming way out of that with work of Viktor Zverovich on std::format and libfmt Those are great, but iostreams hasn't been necessary in a very long time thanks to other libraries like Qt and Boost.
- adev_ 3y ago
  Yes. Several alternatives have been available for a while. The success of Victor has been to make the C++ committee accepts the idea that a new formatter was necessary and to bring <format> in the STL. This was not a small task: The committee has its fair amount of dinosaur gatekeepers and windmills [1]. For the best and the worst. We at least now have a way forward to evolve from <iostream> if we want to with maybe one day the hope of getting something that can entirely replace iostream. [1]: Windmills: Person displacing air around but not much more than air.
  - GuB-42 3y ago
    It is a problem of gatekeeping or just that std::format is actually rather complicated under the hood. For all their flaws, iostreams have the advantage of being simple to implement. They are just overloads of the << and >> operators. std::format and likes require a lot of meta-programming magic to work correctly. It means longer compile times, less tolerance for broken compilers, and possibly weird edge cases, which are important considerations when designing a standard that will be used everywhere. And when it's there, it is there for good, so I understand the committee for being careful. From ANSI C++ to C++20, a lot of work has been done making meta-programming more sensible, and computers became more powerful, which makes it ready for something like std::format.
- GuB-42 3y ago
  Avoiding dependencies is a good thing, especially for C++, that doesn't have a widely used centralized repository and dependency manager like npm, cargo or cpan. For the better or for the worse. And pulling Boost, let alone Qt just to avoid the occasional use of iostreams (or printf) is a bit much IMHO. I usually try to avoid Boost, as I feel it is more of a sort of beta/preview for the standard library. Don't get me wrong, it is production-worthy, but it can lead to awkward things when some boost feature ends up in the standard libraries and the project ends up with bits of both. std::format is great because at last, we can use it without dependencies.
planede 3y ago
I hear you, however something like streambuf is kinda necessary for a type-erased interface for input/output of trivial objects. The C alternative is FILE*, which isn't much better and isn't as customizable either. I agree that the formatting could have been done better, and that part is indeed handled much better in fmt, although personally I dislike format strings. It's much better than printf, granted.
- deleted 3y ago
  [deleted]
- vitaut 3y ago
  {fmt} has internal buffering but it's not yet exposed to users. There is a feature request for it: https://github.com/fmtlib/fmt/issues/2354 https://github.com/fmtlib/fmt/issues/2354. FILE buffering is not too bad but it can be easily optimized: https://www.zverovich.net/2020/08/04/optimal-file-buffer-size.html https://www.zverovich.net/2020/08/04/optimal-file-buffer-siz....
JohnFen 3y ago
Indeed. I heavily dislike iostreams and think it does more harm than good for most use cases.

by adev_ 3y ago

shiroiuma 3y ago

>Fortunately there is an incoming way out of that with work of Viktor Zverovich on std::format and libfmt Those are great, but iostreams hasn't been necessary in a very long time thanks to other libraries like Qt and Boost.

adev_ 3y ago
Yes. Several alternatives have been available for a while. The success of Victor has been to make the C++ committee accepts the idea that a new formatter was necessary and to bring <format> in the STL. This was not a small task: The committee has its fair amount of dinosaur gatekeepers and windmills [1]. For the best and the worst. We at least now have a way forward to evolve from <iostream> if we want to with maybe one day the hope of getting something that can entirely replace iostream. [1]: Windmills: Person displacing air around but not much more than air.
- GuB-42 3y ago
  It is a problem of gatekeeping or just that std::format is actually rather complicated under the hood. For all their flaws, iostreams have the advantage of being simple to implement. They are just overloads of the << and >> operators. std::format and likes require a lot of meta-programming magic to work correctly. It means longer compile times, less tolerance for broken compilers, and possibly weird edge cases, which are important considerations when designing a standard that will be used everywhere. And when it's there, it is there for good, so I understand the committee for being careful. From ANSI C++ to C++20, a lot of work has been done making meta-programming more sensible, and computers became more powerful, which makes it ready for something like std::format.
GuB-42 3y ago
Avoiding dependencies is a good thing, especially for C++, that doesn't have a widely used centralized repository and dependency manager like npm, cargo or cpan. For the better or for the worse. And pulling Boost, let alone Qt just to avoid the occasional use of iostreams (or printf) is a bit much IMHO. I usually try to avoid Boost, as I feel it is more of a sort of beta/preview for the standard library. Don't get me wrong, it is production-worthy, but it can lead to awkward things when some boost feature ends up in the standard libraries and the project ends up with bits of both. std::format is great because at last, we can use it without dependencies.

planede 3y ago

I hear you, however something like streambuf is kinda necessary for a type-erased interface for input/output of trivial objects. The C alternative is FILE*, which isn't much better and isn't as customizable either. I agree that the formatting could have been done better, and that part is indeed handled much better in fmt, although personally I dislike format strings. It's much better than printf, granted.

deleted 3y ago
[deleted]
vitaut 3y ago
{fmt} has internal buffering but it's not yet exposed to users. There is a feature request for it: https://github.com/fmtlib/fmt/issues/2354 https://github.com/fmtlib/fmt/issues/2354. FILE buffering is not too bad but it can be easily optimized: https://www.zverovich.net/2020/08/04/optimal-file-buffer-size.html https://www.zverovich.net/2020/08/04/optimal-file-buffer-siz....

JohnFen 3y ago

Indeed. I heavily dislike iostreams and think it does more harm than good for most use cases.