Earlier quoted context omitted.
let p: Box = Box::new(X { ... }); let x2 = X { ... }; // Moves x2 into the same memory as the first X. // The first X is automatically dropped as part of this assignment. // Also consumes x2 so x2 is not available any more. *p = x2; // Drops the X that was originally assigned to x2 and then moved into p. drop(p); // No need, nor is it possible, to destroy x2.
Thanks for the rust sample. It looks very similar. Can the allocator be customized? As I said I am not Rust specialist. Also, in my understanding is that in Rust, sometimes a dynamic state is created when the object may or may not be moved. In cake ownership this needs to me explicit ( and the destructor is not generated) I also had a look at Rust in lifetime annotations. This concept may be necessary but I am avoidi…
`Box` is the type of an owning pointer that uses the default global allocator, and `Box` is the type of an owning pointer that uses an allocator of type `A`. The latter is unstable, ie it can only be used in nightly Rust.
(Also the fact that the latter changes the type means a large part of existing third-party code as well as a bunch of code in libstd itself becomes unusable if you want to use a type-level custom allocator because they only work with `Box`. But that's a different discussion...)
>An object Y pointed by pY must live longer than object X.
Yes, the py field in Rust would use a reference type instead of a pointer, and the reference would need to have a lifetime annotation, and the compiler would work to prevent the situation you describe:
struct X { py: &'a Y }
let y = Y { ... };
let x = X { py: &y };
drop(y); // error: y is borrowed by x so it cannot be moved.
let y: String = "a".to_owned();
let x = &y;
drop(y); // error: y is borrowed by x so it cannot be moved.
do_something_with(x);