The Sad Truth About C++ Copy Elision

Re:The Sad Truth About C++ Copy Elision by partiallattice on Saturday April 03, 2021 @04:11PM (#26684328)

One tough thing about rule of zero classes is that many to most end up having an implicit 'the object has not been moved from' precondition on methods. The classic example is a class with a unique_ptr member that is never null except after move, so none of the methods have null checks.

I understand why the committee was unable to get destructive moves into the standard, but I do think that is one thing Rust got right that I really wish C++ had.

[ Parent | on HN ]

Re:The Sad Truth About C++ Copy Elision by tragomaskhalos on Saturday April 03, 2021 @06:04PM (#26685151)

People bang on about borrow checking etc but really it's move semantics that's the million dollar idea in Rust - it just obliterates a huge Gordian knot of complexity in one stroke

[ Parent | on HN ]

Re:The Sad Truth About C++ Copy Elision by ncmncm on Sunday April 04, 2021 @04:54AM (#26687903)

In Rust you cannot write a move constructor. That proves limiting. But Rust move construction, also, cannot fail, which is liberating.

Rust cannot abandon backward compatibility with itself, so will increasingly be stuck with old choices, like C++, and will soon be fully as complex and infuriating. But it will, like C++, remain usually more useful than alternatives.

[ Parent | on HN ]

Re:The Sad Truth About C++ Copy Elision by MaxBarraclough on Saturday April 03, 2021 @05:24PM (#26684873)

Agree. Can't really blame C++ for it being difficult to retrofit something like that. It's akin to the lack of const in Java: they'd add it if it were practical to do so.

[ Parent | on HN ]