DLoupe

I think you missed my point. The problem is not lack of guarding against programmer mistakes. It's that the compiler generates unnecessary code.

"Another difference in Rust is that values cannot be used after a move, while they simply "should not be used, mostly" in C++"

That's one of my biggest issues with C++ today. Objects that can be moved must support a "my value was moved out" state. So every access to the object usually starts with "if (have-a-value())". It also means that the destructor is called for an object that won't be used anymore.

and of Even Toned Screens, the halftoning algorithm used by many linux print drivers.

The compiler generates code for calling the destructor after the object was moved. This was problem #1.

Regarding #2, take Resource Acquisition Is Initialization (RAII) as an example - in RAII, the existence of an object implies the existence of a resource. Now, if you want to be able to move, the object becomes "either the resource exists or it was moved out". As someone else noted in the comments, this affects not only the destructor. Methods cannot assume the existence of the resource, they have to check it first. Kind of like optional<MyResource>.

> I wonder what you are doing to get yourself in that situation.

The problem with the current move semantics is that, compared to e.g. Rust: 1) the compiler generates unnecessary code and 2) instead of just implementing class T you must implement a kind of optional<T>.

Which means, that after all those years of using smart pointers I find myself ditching them in favor of plain pointers like we did in the 90's.

By adding syntax and semantics for destructible moves, meaning the moved object is removed from its scope (without calling its destructor.)

Since I use move semantics all the time, this is for me the most frustrating thing about C++ full stop. I really wish they'd fix this instead of adding all those compile-time features.

For example, boost library's "describe" and similar macro based solutions. Been using this for many years.

If you use Google to backup your WhatsApp chats (most people do), Google can already read your messages, because the backup is not encrypted.

It's called "dynamic pricing" and it's everywhere. https://de.wikipedia.org/wiki/Dynamic_Pricing

Thanks so much for replying, Walter. I'll give it another try.

For me, D failed to replace C++ because of lack of design. It is more a mix of great features. But once you start learning the details simple things can get very complicated.

For example, function arguments can be "in", "out", "inout", "ref", "scope", "return ref" - and combinations.

Another example is conditional compilation. Great when used sparely, but can otherwise make it very difficult to understand how the code flows.

In the end, reading the source code of the standard library convinced me against it.

(The source code for the C++ standard library is much worse, of course).

Its's Evil (Evil = Incompetence + Power)

Why $6,2999 when the article says he payed around $900?

> The safety checks have uncovered over 1,000 bugs

In most implementations of the standard library, safety checks can be enabled with a simple #define. In some, it's the default behavior in DEBUG mode. I wonder what this library improves on that and why these bugs have not been discovered before.

The chats are encrypted but the backup saved in the cloud isn't. So if someone gets access to your Google Drive he can read your WhatsApp chats. You can opt-in to encrypt the backup but it doesn't work well.

Oops, he did it again. Congrats Raph, and thanks - your work and your writing have been an inspiration to me for my entire career (~25 years).