It's so you don't have to tether your phone. It might cost you another data plan, but it makes it very convenient to just open your laptop and start browsing the internet in the train or something.
In my company we do so by disallowing constructors to fail. If an object needs to be initialized with the potential of failure you need to call an init() function that returns an error code after construction.
IMO the most important part of RAII is really the other side, "destruction is resource divestment" - and that still works. That is the main purpose of lock guards, refcounting wrappers, file objects and so on.
The safest & fastest way I'm aware of to use a unique_ptr factory. It involves adding an error flag to the class; the factory checks the error flag and resets the unique_ptr if it's true.
C++ constructors cannot express fallibility. Rust factory functions cannot placement-initialize (write into a pointer) an object too big to fit on the stack (aside from the perma-unstable `box` syntax, which I don't know if it even works or not). A unique_ptr factory cannot stack-allocate an object.
I don't know if it's possible to create a safe interface to fallible initialization, which is agnostic to whether the object will be constructed via return onto the stack, or onto heap memory. I'm interested to hear about proposals though (I've discussed this in the Rust community discord, but that isn't as public or concrete as a long-form article).
No, they can. They can throw exceptions. My suggestion moves unsafe-construction onto the heap. Not ideal for a whole host of reasons, including a need to null-check the result -- but you can then move the object to the stack, and drop the unique_ptr. But if you're tying one hand behind your back, contortions will be necessary to accomplish the mundane.
You can only install this on windows in a VM (like Virtual Box). You also can't install it directly, you would need a Linux distribution as well. It would be easier to wait until Ubuntu or Fedora releases a new version which contains this version of GNOME. Desktop Environments on Linux are basically GUI themes.
Not only are they GUI themes, some desktop environments come packaged with different utility software. (e.g. Gnome comes with GTK-based utility software like Gedit, and KDE comes with KDE-based utility software like Kwrite.
I think you have to upgrade your laptop often or you won't keep up with the increasing requirements of software. I have a similar flow as you do (tons of apps, tabs, Linux workspaces, code compiling, video running etc). I also get easily annoyed when I do some basic stuff and all of a sudden the computer lags behind, is stuck etc.
in the end I went with a desktop computer (if you have the space and you don't mind losing portability - I also have a Dell XPS in a pretty good shape for when I need it). It does waaay better when it comes to multitasking, never gets sluggish, much easier to upgrade, no throttiling/overheating problems, cheaper.
> In that research, Rust had the same overall count of bugs and even some 'zero day' sort of ones not any different from C++ and C codebases (maybe just better than the C one).
That's actually not entirely true. One of the problems was the program taking too long to compete due to suboptimal algorithm. The GitHub repo showed that the tests were run using debug version of the Rust binary. It worked fine when people tried to reproduce using the release version.
For the other two problems, not many details were given, but both programs panicked immediately with the given input. That's still better than any kind of undefined behaviour or silent error.
