7 ms·

It can be pretty safe, but it requires restraint and selecting a good subset of the language. There's still plenty of footguns that an inexperienced person migh

It can be pretty safe, but it requires restraint and selecting a good subset of the language. There's still plenty of footguns that an inexperienced person might hit.

amluto 5y ago
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.
- pas 5y ago
  Could you please explain this? I remember something about rvalues but it was as ages ago apparently :)
- deleted 5y ago
  [deleted]
- swader999 5y ago
  First time I've ever heard the term 'footgun'
  - josephg 5y ago
    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.”
- rightbyte 5y ago
  The temporary's reference is valid until the temporary is destroyed by falling out of scope, swapped etc. Or have I missed something?
  - esrauch 5y ago
    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.
  - amluto 5y ago
    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.)
zmmmmm 5y ago
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.
- UncleMeat 5y ago
  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.
  - esrauch 5y ago
    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.

It can be pretty safe, but it requires restraint and selecting a good subset of the language. There's still plenty of footguns that an inexperienced person might hit.

amluto 5y ago

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.

pas 5y ago
Could you please explain this? I remember something about rvalues but it was as ages ago apparently :)
deleted 5y ago
[deleted]
swader999 5y ago
First time I've ever heard the term 'footgun'
- josephg 5y ago
  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.”
rightbyte 5y ago
The temporary's reference is valid until the temporary is destroyed by falling out of scope, swapped etc. Or have I missed something?
- esrauch 5y ago
  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.
- amluto 5y ago
  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.)

zmmmmm 5y ago

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.

UncleMeat 5y ago
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.
- esrauch 5y ago
  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.