And footguns that an experienced person might hit. One family of such footguns is:

    const auto &foo = something(args);
    …
    other_thing(foo);

Depending on exactly what you’re doing and what type something(args) returns, this can be entirely correct and idiomatic. In other circumstances it accesses a reference after its lifetime.

One can debate whether the const belongs there and how many &’s to use, but, unless something has changed dramatically in the last couple years (I’ve been focused on things that aren’t C++), there is no answer that is universally safe and efficient.

The temporary's reference is valid until the temporary is destroyed by falling out of scope, swapped etc. Or have I missed something?

The reference itself is indeed valid, in the sense of existing, until it falls out of scope. But the object it references may not be, so using the reference can be UB. Consider an std::vector v with length known to be at least 1:

    const auto &ref = v[0];
    v.push_back(42);
    cout << ref;

That works fine until push_back reallocates out of place, at which point you may start to notice that it’s actually UB.

Rust will not permit this problematic usage. GC languages tend not to offer this pattern — you can reference a boxed vector element with different semantics than the above C++ code, and you mostly can’t reference an unboxed element. C++ lets you do things like this but has little ability to statically verify correctness.

(Doing the above maneuver with a vector is a bit silly: it saves typing, and indexing a vector is extremely fast. With a map, though, indexing is not so fast, and keeping an iterator or a reference around may be a big performance win. At least if you keep an iterator around, dynamic checkers have a better chance of noticing errors.)

I think the point is just that unlike Rust there's no compiler enforcement that you only use refs in their lifetimes: you can easily accidentally cause a use after free.

Some times it can be pretty indirect: eg if the ref ends up pointing into some std container then it might need invalidated by making an otherwise unrelated change to the container.

Could you please explain this? I remember something about rvalues but it was as ages ago apparently :)

First time I've ever heard the term 'footgun'

It’s a reference to a decades-old quote from Bjarne Stroustrup, C++’s creator:

“In C++ it’s harder to shoot yourself in the foot, but when you do, you blow off your whole leg.”

It's not even so much that the footguns exist but that the consequence of hitting them is "undefined behavior" ie: anythign from core dump to reformatting your hard drive. Compare to Java where the consequence is one thing doesnt work right and someone has to debug it. Rarely it takes down a whole server side process but even then you get a lot of instrumentation and diagnostics to manage it and / or figure out what happened.

C++ is a nightmare language but this specific complaint is completely overblown. The compiler isn't going to format your hard drive (I know that one blog post exists - that is a deliberately constructed example).

A C++ program with UB is just buggy. Same as a java program with bugs. The program does something you don't want it to do. That's what a bug is. The compiler isn't going to maliciously introduce code that you didn't write to order pizzas.

I think there is a factor of UB that makes it have a steeper learning curve than the corresponding issues in other languages: with Java a lot of that category of bad code will throw exceptions and you'll get useful stack traces. UB often results in some seemingly nonsensical runtime state (eg something being null immediately after a null check, or a null dereference only leading to a segfault later in a place that locally has no pointers).

Compare mutating a container in a way that invalidates a live iterator: in java it's a specific exception that you can read on stack overflow, and in C++ it's just a use after free that might still appear to work correctly a random percentage of the time.