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?