I sincerely hope that whoever decided that a) this action needs a shortcut and b) to overload the most common hotkey spends the rest of eternity toiling away at features nobody wants, slowly ruining their company, and never, ever gets that sick promotion they're desperately chasing. I hope their wife leaves them and takes the dog.
Enumerate all well formed programs in order. For programs that halt assign the digit 0, and for the ones that don't, the digit 1. Put the digits after a decimal point and interpret in binary.
On windows and linux, yes, without any added anything holding the shift (or windows or control or alt) key on one keyboard will modify the behavior of any key with any other keyboard (I have a vague memory of getting 3 keyboards and hitting ctl-alt-del across the three keyboards, on windows, and it behaving "normally").
You need some added tools to make it work with macos, as someone else pointed out
These days I just use a single keyboard (the IBM M4-1 keyboard) and get up frequently.
Not to mention that the `scope_success` and `scope_failure` variants have to use `std::uncaught_exceptions()`, which is hostile to codegen and also has other problems, especially in coroutines. C++ could get exception-aware variants of language defer.
While not automated, you can make use of function-try-blocks, e.g.:
struct Example {
Example() = default;
~Example()
try {
// elease resources for this instance
} catch (...) {
// take care of what went wrong in the whole destructor call chain
}
};
What I’m thinking of is that the C++ exception runtime would attach exceptions from destructors to any in-flight exception, forming an exception tree, instead of calling std::terminate. (And also provide an API to access that tree.) C++ already has to handle a potentially unlimited amount of simultaneous in-flight exceptions (nested destructor calls), so from a resource perspective having such a tree isn’t a completely new quality. In case of resource exhaustion, the latest exception to be attached can be replaced by a statically allocated resources_exhausted exception. Callbacks like the old std::unexpected could be added to customize the behavior.
The mechanism in Java I was alluding to is really the Throwable::addSuppressed method; it isn’t tied to the use of a try-block. Since Java doesn’t have destructors, it’s just that the try-with-resources statement is the canonical example of taking advantage of that mechanism.
reply