2 ms·
> It's a high-level object (i.e. not a pointer) I don't know why so many people in this thread try to pretend that there's no reason to see Box as a pointer, n
by remram 3y ago
> It's a high-level object (i.e. not a pointer)
I don't know why so many people in this thread try to pretend that there's no reason to see Box as a pointer, no one has ever called it that, and every user drawing a parallel is confused. The documentation for Box is literally (emph mine):
>> *A pointer type* that uniquely owns a heap allocation of type T.
Until that documentation changes I find the article's point quite valid.
- CodeMage 3y ago> The documentation for Box is literally (emph mine): > >> A pointer type that uniquely owns a heap allocation of type T. > Until that documentation changes I find the article's point quite valid. I think there's some confusion here and that it's because the concept of "pointer" is slightly overloaded. One overload of the meaning is "first-class pointer types": https://doc.rust-lang.org/reference/types/pointer.html https://doc.rust-lang.org/reference/types/pointer.html The other overload, the one used in the docs for Box, Rc, and such, is basically "anything that implements Deref". People who say "Box is not a pointer" are referring to the fact that Box is not a first-class pointer type, i.e. it's neither a reference nor a raw pointer.
- ComputerGuru 3y agoI only meant "not a raw pointer" because rust supports read and write operations on raw pointers with very different aliasing semantics. It is an owned pointer, with emphasis on the "owned". You can have as many raw pointers to the same memory location as you like, you just can't have multiple native rust objects pointing to that same memory alive at once, though. It's also obvious because Box<T> implements Drop, so obviously it's not just something you can pass to a function in lieu of a pointer and if you do pass it to a function, you can no longer make any assumptions about the lifetime or validity of any pointers to the same data.