My understanding is that at the bottom it still calls the c-related content, but it just does some security aspects, is that right?
If my understanding is wrong, can you tell me what the correct understanding is and how the source code of rust is associated with box?
It's unclear what you are asking, what this has to do with C, or what you mean by "associating source code".
box is an internal (and deprecated) keyword for creating a value of type Box<T>; the stable and equivalent way to achieve this is the long-available Box::new() function.
These are multiple issues.
- what is the essence of the
boxkeyword in the source code of rust, my understanding is that in the call to memory allocation is actually the operation of c-related code, in other words the underlying principle mechanism of box is dependent on c. I do not know if this is the right understanding, and if not the correct understanding is what kind of? My purpose is to explore what the underlying nature ofboxis and how memory allocation is done?
If my first understanding is correct, how isboxassociated with the code in the rust source code architecture, because I just see the keywordbox.
It doesn't matter. For the most part, I think Rust doesn't use malloc() from libc, if that's what you are asking for. The language has its own memory allocator, and it's also possible to customize it. If you are trying to free() a pointer derived from a Box, then simply don't.
There is no "essence" to the box keyword other than "it's the same as Box::new()". It was never stable, it's deprecated, and as you can also see, it's been removed from even most of the standard library itself.
My current understanding is that rust is built on top of c. In other words at the bottom some memory allocation is done through c and then the allocated memory blocks are associated with the type system of rust. One of the reasons why I understand this is that rust has to adapt to many operating systems (the core of the operating system is written by c) and the use of resources in different operating systems, if it does not rely on c I don't think this can be done without relying on c
I don't know if this is the right understanding?
Not necessarily - there's ongoing efforts to create a pure-Rust implementation of libc APIs, for example.
Not necessarily even with glibc or musl - system allocator is used by default, but it can be replaced with some other allocator, either C-based (e.g. jemalloc) or pure-Rust.
It can't be done without relying on C ABI (since this is de-facto standard stable way to do FFI, including calls to assembly), but there's no obligation in using any C code.
2 Likes
I still don't quite understand, can you give me a detailed analysis from the overall this problem has bothered me for a long time.
I'm less expert than the others replying here so I'll just try to clarify for my own understanding, in the hope that I'll be corrected if I'm egregiously in error.
System in std::alloc - Rust explains there is a 'default allocator'. This is malloc on Linux, provided by either the glibc or musl shared lib depending on your distro. On Windows it'll be HeapAlloc from the Win32 API. So, yes, by default all memory allocations performed in std (whether by box or Box::new or anything else) require calls to libraries written in C (or C++ I think for the Win API?).
But the allocator used in the Rust std is configurable via the #[global_allocator] attribute, so the dependence on C/C++ libs is only de facto. Rust is not 'built on C' - it just calls into shared libraries that in the most common environments (Linux, the BSDs, Windows) happen to be written in C/C++. Other allocators can in principle be used, eg. a possible pure Rust implementation.
As far as I understand it, the non-dependence of Rust on C is even more in evidence when using it without an OS, where only Rust core is used - ie. no std::*. In this case there's no allocator provided, so no 'C' or any other library (unless you choose to use one).
1 Like
There's also the WASM target, which has no libc at all.
1 Like
The box keyword is obsolete. A prehistoric Rust version use to have ~T syntax for heap-allocated types, @T for reference-counted types, and &T for loans. Only the last sigil survived, ~T became box T and then Box<T>.
Now heap allocations are done with Box::new, which is mostly a regular method, but there's still a bit of compiler magic around Box, because Box supports move out of reference which other types aren't allowed to (a feature proposed as DerefMove).
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.