C++ and zombies: a moving question

Oh, the destructive move problem. I thought this was about "re-animation", the horror introduced with Microsoft Managed C++, where, if a GC-called destructor saves a pointer to the object being destroyed, the object has to be "re-animated".

No, this is just the destructive move problem for single ownership pointers. It's an use case for "swap" as a language primitive.

The real problem is that you just can't make single-ownership pointers work right in C++ via the template mechanism. I tried a few times, over a decade ago. (http://animats.com/papers/languages/index.html) It takes a more global look than you have down inside a template. You need language-level support.

Rust does this. It's not inherently hard. It's just extremely hard to retrofit to the C++ model. Look at the history of auto_ptr, and now unique_ptr in C++. The pain. The anguish. The decades of headaches. The unnecessary complexity. The pain.

The biggest problem with destructive move in C++ (and one I personally think is unfixable, but I'm happy to be proved wrong), is that in most cases algorithms must be sure to recreate any variable they are not responsible for, as it will be destroyed later. There isn't any way of checking if some memory has already been destroyed, and adding any kind of flag just gets us back to the same position really. In particular I tried writing an exception safe std::sort (so make sure when std::sort exits all variables are reconsructed again), and it is an extremely difficult undertaking.

In general I find the lack of destructive move isn't a serious problem -- designing variables so their 'default state' is very cheap to construct isn't usually a major cost.

I think it was Dave Abrahams who first brought up the issue of destructors with side effects and their implications for move semantics. For example, a destructor may have the side effect of releasing a lock. If I remember correctly, Dave's advice was to write your move operations in such a way that they always perform at least those destructor actions that have side effects. I seem to remember that he discussed this on his cpp-next blog, but the site appears to be down. Does anybody know if those blog posts are available somewhere?

Consider a Movable file handle.

File fh = File(fopen("file.txt"));

foo(std::move(fh));

Using fh after foo() would yield a compile error in Rust. It does not in C++.

I feel like a complete idiot when I read these articles :-( I can hardly even understand the issues because c++ have gotten to a point where I have to strain myself very hard to even understand the problem (forget the solution). And I have been programming with c++ for many years (but c++11 ignorant).