[c++] Consider implementing Drop for types with destructors

[Volker-Weissmann]

Consider the following C++ code:

#include "stdio.h"
class Inner {
public:
	Inner();
	~Inner();
};
Inner::Inner() {
	printf("constructing Inner\n");
}
Inner::~Inner() {
	printf("destructing Inner\n");
}
class Outer {
	Inner in;
public:
	Outer();
	~Outer();
};
Outer::Outer() {
	printf("constructing Outer\n");
}
Outer::~Outer() {
	printf("destructing Outer\n");
}

If you use bindgen to execute

let mut val = Outer::new();
val.destruct();

You get the output

constructing Inner
constructing Outer
destructing Outer
destructing Inner

Which is also the output of the C++ code

#include "wrapper.cpp"
int main() {
	Outer obj;
}

If we now remove the ~Outer() deconstructor, this C++ code outputs

constructing Inner
constructing Outer
destructing Inner

But the rust code

let mut val = Outer::new();
val.destruct();

no longer compilers because Outer::destruct does not exist and the rust code

let mut val = Outer::new();

just outputs

constructing Inner
constructing Outer

which might result in memory leaks or similar bugs.
A similar problem arises if you remove the default constructor.

Is it possible to automatically add constructors and destructors that call the constructors and destructors of the member variables?

[kulp]

From the bindgen user guide,

using those types in Rust will be nowhere near as nice as using them in C++. You will have to manually call constructors, destructors, overloaded operators, etc yourself.

I am not sure if that is the end of the story, but I think your reasonable request might be more than bindgen can reasonably provide.

[emilio]

Yes, you need to implement Drop yourself, because it can cause unsoundness otherwise.

For example, if bindgen would implement Drop by default, dropping Outer would end up calling ~Inner twice, once from Rust, once from C++, which is bad.

We could fix that using ManuallyDrop for members of structs that have destructors nowadays, I think.

[Volker-Weissmann]

Two things:

1. You said that Feature request: Drop trait deconstructor #1841 is the same as this issue and renamed this issue. But adding the default destructor/default constructor and calling the deconstructor using the drop trait are two seperate things. You can do the first thing without doing the second.

2. I understand and could reproduce the problem of ~Inner being called twice. I think that some kind of hacky solution (maybe using ManuallyDrop) would be really valuable. One way to do this would be to autogen the following:

Outer* wrap_outer_construct() {
	return new Outer();
}
void wrap_outer_destruct(Outer *ptr) {
	assert(ptr != NULL);
	delete ptr;
}

struct wrap_outer {
	ptr: *mut Outer
}
impl wrap_outer {
	fn new() -> wrap_outer {
		let cptr = unsafe {
			wrap_outer_construct()
		};
		wrap_outer{ptr: cptr}
	}
}
impl Drop for wrap_outer {
	fn drop(&mut self) {
		unsafe {
			wrap_outer_destruct(self.ptr);
		}
	}
}

The disadvantage of this is that you can no longer access the member variables (or autogen getters/setters?).

[emilio]

You said that #1841 is the same as this issue and renamed this issue. But adding the default destructor/default constructor and calling the deconstructor using the drop trait are two seperate things. You can do the first thing without doing the second.

Well, kinda, right? If we auto-implement drop, then default constructors between Rust and C++ behave the same don't they?

I'm not sure under which circumstances a C++ compiler emits symbols for a default constructor, if it does at all. If you have info on that we can try to elaborate a solution for it.

[Volker-Weissmann]

You said that #1841 is the same as this issue and renamed this issue. But adding the default destructor/default constructor and calling the deconstructor using the drop trait are two seperate things. You can do the first thing without doing the second.

Well, kinda, right? If we auto-implement drop, then default constructors between Rust and C++ behave the same don't they?

I'm not sure under which circumstances a C++ compiler emits symbols for a default constructor, if it does at all. If you have info on that we can try to elaborate a solution for it.

No. #1841 is about pub fn destruct(&mut self) being called automatically, #1840 is about pub fn destruct(&mut self) existing if there is no ~MyClass() in the C++ code. The reason I opened #1840 is that adding ~MyClass(){} does not change anything in a pure C++ program, but it changes something for bindgen.

[barakugav]

I think its safe to automatically generate Drop for opaque types as destructors of inner fields will not be called twice.
@emilio what do you think?