The entire I/O streams (where std::cout comes from) feature is garbage, if this was an independent development there is no way that WG21 would have taken it, the reason it's in C++ 98 and thus still here today is that it's Bjarne's baby. The reason not to take it is that it's contradictory to the "Don't use operator overloading for unrelated operations" core idea. Bjarne will insist that "actually" these operators somehow always meant streaming I/O but his evidence is basically the same library feature he's trying to justify. No other language does this, and it's not because they can't it's because it was a bad idea when it was created, it was still a bad idea in 1998, the only difference today is that C++ has a replacement.

The modern fmt-inspired std::print and std::println etc. are much nicer, preserving all the type checking but losing terrible ideas like stored format state, and localisation by default. The biggest problem is that today C++ doesn't have a way to implement this for your own types easily, Barry illustrates a comfortable way this could work in C++ 26 via reflection which on that issue closes the gap with Rust's #[derive(Debug)].

Perfectly iostreams happy user since 1993.

Same, as long as I stay the hell away from locales/facets.

Type safe input/output stream types and memory backed streams served on a silver plate is a pretty decent improvement over C.

int a;

cin >> a;

Then the program goes berserk as soon as the first non-number is read out of standard input. All the other "cin >> integer" lines are immediately skipped.

Yes, I know about error checking, clearing error condition, discarding characters. But it's a whole lot of stuff you need to do after every single "cin>>" line. It makes the simplicity of cin not worth it.

How could you ever continue after the second statement without checking if you actually read an integer or not? How would you know what you can do with a?

You couldn't or wouldn't. but why have a read statement like cin>> which looks so nice and clean when you then have to go and check everything with flags and boolean casts on stateful objects.

I agree. It's lunacy. just be explicit and use functions or equivalent like literally every other language.

Well in a language like Haskell you could solve this with monads and do-notation. The general idiom in Haskell is to use a Maybe or Either monad to capture success/failure and you assume you’re on the happy path. Then you put the error handling at the consumer end of the pipeline when you unwrap the Maybe or Either.

I believe Rust has adopted similar idioms. I’ve heard the overall idea referred to as Railway-oriented programming.

In C++ you could implement it with exceptions, though they bring in a bunch of their own baggage that you don’t have to deal with when using monads.

You’re holding it wrong. Like nan, the point is you don’t have to error check every operation.

You check error for the whole batch.

   fscanf (STDIN, "%d", &a);

the program goes beserk as soon as the first non-number is read out of standard input.

in both cases, you need error checking (which you "know about").

No actual C programmer who has been around the block more than halfway should do that. The mantra is: "read into a character buffer, then parse that".

It's more code, sure, but it buys you a lot of good things. I/O is hard.

No C++ programmer who has been around the block more than halfway should do

    cin >> a;

and assume that it works.

But also ...

    sscanf (the_buffer, "%d", &a);

doesn't help the problem in any substantive way.

Yep, it’s very clean once you get the hang of it.

Then I suppose you don't care about:

* Performance

* Support for localization (as the format string and positions of values to format differ between languages).

* Code reuse & dogfooding - the data structures used in iostreams are not used elsewhere, and vice-versa

* C and OS interoperability - as you can't wrap a stream around a FILE* / file descritor

* bunch of other stuff...

iostreams work, but are rather crappy.

I care about performance, when it actually matters to acceptance testing.

The less C the merrier.

If you care about correct use of localisation, standard C and C++ libraries aren't really what you're looking for, or even C and C++ to start with.

C and C++ are the bedrock of operating systems with the best performance and extensive support for all languages.

The only reason why iostreams are slow is because of its incompatible buffering scheme, and the fact that C and C++ need to stay in sync when linked together. And that brand of slow is still faster than other languages, except sometimes those that delegate i/o to pure C implementations.

Historical baggage, they weren't the first system programming languages, got lucky with UNIX's license allowing for widespread adoption, and won't be the last one standing either.

Considering that they are evolving, I think they are more likely than not to stay standing. There might be other similar languages developed in parallel, but after over 30 years of whining C and C++ are still popular. I don't expect that to change.

    > If you care about correct use of localisation, standard C and C++ libraries aren't really what you're looking for, or even C and C++ to start with.

What do you recommend instead?

_("some text") ... aka gettext and friends.

QT, unfortunately.

Why do you "unfortunately"?

It's like using a sledgehammer for a picture hook. I think QT is a great tool, and it solves this problem nicely, but it's a full blown framework, and if you're already using something else - particularly if it's something "light" like SDL, or just a platform specific library like Win32, it's an awful lot to pull in (plus compile times, licensing, etc).

If you are using SDL, what is wrong with GNU gettext()?

This was a tip my hatn excellent to you

Why?

Thank you.

> The biggest problem is that today C++ doesn't have a way to implement this for your own types easily

I’m not sure about the stdlib version, but with fmtlib you can easily implement formatters for your own types. https://fmt.dev/11.0/api/#formatting-user-defined-types

I think the problem is that your idea of "easy" is "Here's a whole bunch of C++ you could write by hand for each type" while the comparison was very literally #[derive(Debug)]. I wasn't abbreviating or referring to something else, that's literally what Rust programmers type to indicate that their type should have the obvious boilerplate implementation for this feature, in most types you're deriving other traits already, so the extra work is literally typing out the word Debug.

What’s wrong with it?

>No other language does this, and it's not because they can't it's because it was a bad idea when it was created, it was still a bad idea in 1998, the only difference today is that C++ has a replacement.

Hindsight is 20/20, remember that. Streams are not that bad of an idea and have been working fine for decades. You haven't named a problem with it other than the fact the operators are used for other stuff in other contexts. But operator overloading is a feature of C++ so most operators, even the comma operator, can be something other than what you expect.

>The biggest problem is that today C++ doesn't have a way to implement this for your own types easily, Barry illustrates a comfortable way this could work in C++ 26 via reflection which on that issue closes the gap with Rust's #[derive(Debug)].

You can trivially implement input and output for your own types with streams.

You appear to be a Rust guy whose motive is to throw shade on C++ for things that are utterly banal and subjective issues.

What they mean is this:

     struct Foo {
       int a;
       float b;
       std::string c;
     };


     Foo foo;
     std::cout << foo;

with no extra code. It's called reflection, where the compiler can generate good-enough code to generate a character-stream serialization of an object without any human intervention.

I know what reflection is of course. C++ makes it easy to implement IO. If you're asking for a reflection-based solution with less effort, you are practically asking for zero extra code. Anyway, C++ does not yet have reflection but who's to say how anyone wants any particular data to be dumped? A default implementation is nice but less useful than you make it sound. In any case, there are libraries approximating what you described (usually with macros and stuff) and reflection is totally coming at some point.

Remember that C++ originally didn't have variadic templates, so something like std::format would have been impossible back in the day. Back in the day, std::iostream was a very neat solution for type safe string formatting. As you conceded, it also makes it very easy to integrate your own types. It was a big improvement over printf(). Historic perspective is everything.

{fmt} used to support pre-C++11 compilers that didn't have variadic templates. It was a pain to emulate variadics but it wasn't impossible.

Wow, I don't know that! I would be curious to know how they did it.

Oh, I didn't realize you're the author! Thank you so much for fmt/std::format - it's truely a godsend!

Glad you like it =)

It was emulated using horrible macros: https://github.com/fmtlib/fmt/blob/8f5e07656e25ec64ec7c843f0.... IIRC some early versions of `std::tuple` did something similar.

Over the years, I have heard numerous complaints about C++ I/O streams. Is there a better open source replacement? Or do you recommend to use C functions for I/O?

https://en.cppreference.com/w/cpp/utility/format for C++20 and https://en.cppreference.com/w/cpp/io/print for C++23

https://github.com/fmtlib/fmt is what it's based on, for C++11 and up support.

> Don't use operator overloading for unrelated operations

This disn't stop with <iostream>, they keep doing it - the latest example I can think of is std::ranges operations being "piped" with |.

> The entire I/O streams (where std::cout comes from) feature is garbage, if this was an independent development there is no way that WG21 would have taken it, the reason it's in C++ 98 and thus still here today is that it's Bjarne's baby.

I think this is a very lazy and somewhat conspiratorial take.

C++'s IO stream library, along with C++'s adoption of std::string, is a response to and improvement over C's standard library support for IO. That alone makes it an invaluable improvement. It's easy and very lazy to look back 30 years ago and badmouth things done back then.

It's also easy to complain about no one proposing changes when literally anyone, including you, can propose changes. The only need to do the legwork and put their money where their mouth is. The funny part is that we see frameworks putting together their own IO infrastructure and it ends up being not good, such as Qt's take on IO.

But talk is cheap and badmouthing doesn't require a pull request.

The problem is precisely that C++ iostream library was, in practice, not an improvement on C stdio in many ways. Some of us were actually there 30 years ago, and even right after C++98 was standardized, it was pretty common for (then-)modern C++ projects to adopt all of stdlib except for iostreams (and locales/facets, another horrible wart).

Sather (1991) used operator overloading for output. And, even more hilariously, they overloaded + in the same way as C++ overloaded <<, giving you:

   #OUT + "Hello, " + name + "!";

I did not know this nor indeed that Sather existed. Thanks. I don't feel as though "But Sather did it too" counts as a good reason for I/O streams, but thanks for telling me.

I don't think it's a good reason, and FWIW I'm pretty sure they got the idea from C++ - iostream design predates ISO C++ by quite a bit. I remember seeing << for that with stuff like Borland C++ 3.1 that also originates in 90s, back when you had to write #include <iostream.h> etc. Just noting that this is not such an obviously bad idea that nobody else hasn't fallen into the same trap.

C++ can seamlessly include C89 headers.

The C library headers for libraries I write often include C11/C99 stuff that is invalid in C++.

Even when they are in C89, they are often incorrect to include without the include being in an `extern "C"`.

Extern "C" around the prototypes is mandatory, otherwise your linker will search for C++ symbols, which cannot be found in the C libraries you pass it.

Not only prototypes but typedefs with function pointers as well.

Clang supports C11 - 23 in C++, as well as some future C features like fixed-point integers. The main pain points with Clang are just the fundamental differences like void* and char, which don't typically matter much at an interoperability layer.

There's a lot of subtle differences between 'proper' C and the C subset of C++, since C++ uses C++ semantics everywhere, even for its C subset.

Many C++ coders are oblivious to those differences (myself included before I switched from 'mainly C++' to 'mainly C') because they think that the C subset of C++ is compatible with 'proper' C, but any C code that compiles both in a C++ and C compiler is actually also a (heavily outdated) subset of the C language (so for a C coder it takes extra effort to write C++ compatible C code, and it's not great because it's a throwback to the mid-90s, C++ compatible C is potentially less safe and harder to maintain).

For instance in C++ it's illegal to take the address of an 'adhoc-constructed' function argument, like:

    sum(&(bla_t){ .a = 1, .b = 2, .c = 3, .d = 4 });

(godbolt: https://www.godbolt.org/z/r7r5rPc6K)

Interestingly, Objective-C leaves its C subset alone, so it is always automatically compatible with the latest C features without requiring a new 'ObjC standard'.

Because Objective-C initial proposal is that everything that isn't touched by Smalltalk like code, clearly in brackets or @annotarions, is plain C.

The pre-processor original compiler, before the GCC fork, would leave everything else alone, blindly copying into the generated C file.

Yeah plenty of headers first have `#ifdef __cplusplus` and then they add `extern "C"`. And of course even then they have to avoid doing things unacceptable in C++ such as using "new" as the name of a variable.

It takes a little bit of an effort to make a header work on C and C++. A lot less effort than making a single Python file work with Python 2 and 3.

The '#ifdef __cplusplus extern "C" { }' thing only removes C++ name mangling from exported symbols, it doesn't switch the C++ language into "C mode" (unfortunately).

> C++ code can seamlessly add #include "sqlite3.h" unchanged.

Almost seamlessly. You have to do

  extern “C” {
    #include "sqlite3.h"
  }

(https://isocpp.org/wiki/faq/mixing-c-and-cpp#include-c-hdrs-...)

If we're nitpicking then sqlite3.h already has `#ifdef __cplusplus` and `extern "C" {`. So yes, from the user's perspective it is seamless. They do not need to play the `extern "C" {` game.

Yep; I think of it as "C/C++" and not "C" and/or "C++" i.e. one "multi-paradigm" language with different sets of mix-and-match.

kinda like python and ruby