As a long-time C++ coder, I need to add that project-specific prohibition of some C++ practices is a pretty normal, even recommended thing to do. Introducing such prohibitions is not a fault of C++.

Also, I observed that "bad experience with C++" is often related to someone using, while not completely understood, some more advanced C++ paradigm.

> project-specific prohibition of some C++ practices is a pretty normal, even recommended thing to do.

So there's a need to subset C++. I wonder. If we took the union of the most common subsets, would we have all of C++, or only parts of it? Which parts of C++ are unsuitable for any project?

If there is any, it is totally the fault of C++ if we have to subset it. Historical reasons yada yada, I don't care: a language you have to subset is still worse than the subset itself.

JavaScript is widely subset, and yet it remains inexplicably held in high esteem.

Could it be more that C++ is a decent language that is fashionable to hate on?

JavaScript held in high esteem? You can't be serious? That language is way too flawed: equality operator that's not transitive, wicked scoping rules, semicolon that you can omit but really shouldn't… And you're telling me this poor Self copycat is held in high esteem? How? Because it took over the web? That's not enough.

As for C++… That language is just too big for its own good. It tries to be too many things to too many people, and as a result is almost never the best choice. (Discounting code already written and available expertise of course. I'm judging the language, not the ecosystem.)

The idea of C++ is a good one, under a couple conditions: first, it must be tuned to a domain or a way of programming. Second, it must not try to be goddamn source compatible with C. If we're writing a language, we might as well correct C's mistakes along the way.

I don't use C++ for anything serious, can you explain what's wrong with exceptions and the std lib?

I wouldn't say "wrong", this is a subjective issue, and some people like them. It's just that exceptions can be dangerous, in a sense, because a very innocuous looking line of code or function call can end up executing something you don't expect, or your function can bail out before you expect. It's similar to how inheritance and virtual functions hide (encapsulate) what's going on, but also obscure execution too. Usually the encapsulation is good, but when you need to know exactly what's going on, they can throw wrenches at you. It can be really hard to figure out all the possible errors that could be thrown, or code paths that could be taken in any given case.

I don't know the specific reasons std lib was mentioned, that's a big topic. But generally in the context of a game engine, you need all custom memory management and I/O, so there isn't much place for std lib, depending on which std lib pieces and which platforms and which C++ you're talking about.

For exceptions: - A bit unpredictable (hard to optimize)

- Introduce a lot of exit points which are hard to find

- They deviate from the "pay what you use," since they generate some extra code

- They can introduce some nasty performance penalties (I experienced this myself a few yeas back, the compilers might be smarter these days, maybe)

About the stdlib: There's a "myth" that often times the stdlib/stl is slow and doesn't do what you expect (unless you've thoroughly read the documentation, which everyone should do anyway). I can't say I was personally affected by this since I also use C++ for nothing too serious. I said "myth" because the argument against the slowness it that this is an outdated notion.

Most C++ compilers these days should have zero cost exception handling, meaning that the non-exceptional path should be free. This works by making the compiler add exception handler data to the executable file, ie. telling where the catch() blocks are. When an exception is thrown, the stack trace is analyzed and the appropriate catch handler is found by searching for the return addresses in the exception handler data.

This can make C++ with exceptions faster than C with error checks because there's no branches to check for every error condition. Using __builtin_expect for marking the error conditions as unlikely may mitigate this issue.

The cost is that you have to ensure that all your code is exception safe unless you are extremely careful to ensure that exceptions are only thrown in places you've expected and coded for.

Exception safe code is both difficult to write correctly and often has a significant run time cost.

Agreed on both accounts but the grandparent comment was talking about runtime performance penalty, which is gone (for the non-exceptional path) in modern implementations.

But yes: exception safety, even basic safety (don't leak resources or crash) is difficult, let alone strong exception safety (no side effects if exception occurs).