[quicknir]

I think the author blows his credibility very early with this comment:

> As I said, it’s a superficial example, but I think it shows a general difference in philosophy between C++ and D. (If I wanted to make the difference even clearer, I’d use an example that needed iomanip in C++.)

iostreams are not in C++ because C++'s philosophy is actually that iostreams are great. Everyone knows they suck. They are there because without variadics, there isn't a good way to do type safe text output in the style of printf. And I mean, not even runtime type safe. Chaining of some kind is the obvious way to simulate variadics when you don't have variadics. And at the time, they thought it was better to get something type safe into the standard library, then gate it behind variadics which could (did) take a long time. Voila, iostreams.

C++ is quite literally in the process of standardizing a library that will bring type safe printf (a la D) to C++. The same way that 8 years ago, C++ finally managed to standardize variadics after quite a lot of effort.

The disadvantage of being an old language is that it can be hard to stay caught up with features. The advantage is that you get a huge base of existing developers, knowledge, libraries, etc.

Bloggers love to make things about big picture philosophy because it makes for better blurbs but many things in reality are just engineering decisions. D had the luxury of creating metaprogramming syntax from scratch after one if its creators was one of the main people to discover the power of "accidental" TMP in C++. C++ is still trying to bend accidental TMP into something more bearable to use without breaking everything. The differences here are more practical than philosophical.

[munificent]

> They are there because without variadics, there isn't a good way to do type safe text output in the style of printf.

I think an equally important point is that IO streams in C++ are extensible. You can make your own user defined types work with them. There's no way to add "printf() support" to your own type in C.

[flukus]

> I think an equally important point is that IO streams in C++ are extensible.

Not sure how portable it is but you can define conversions for your own types: http://www.gnu.org/software/libc/manual/html_node/Customizin... . The format and format_arg attributes give you compile time support: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attribute... .

[pjmlp]

It is just GCC C.

[flukus]

It's part of libc, so not GCC specific, it's basically native on linux and usable just about anywhere you'd want printf functionality. If the bloat (like this feature) of gnu libc are too much then I doubt the c++/d/rust equivalents will be an acceptable option. Likewise if gcc and clang (which supports printf) aren't possible then I very much doubt the platform is a compiler target for modern c++/d/rust.

[lifthrasiir]

In my opinion the most interesting aspect of iostream is the ability to inject a state to the stream: xalloc, iword and pword; they are required to make your own manipulators like `hex` or `setw`. Of course, this is to support a (questionable, again in my opinion) design of manipulators conceptually affecting the state of stream, and there are many saner alternative designs not requiring this kind of "extensibility".