{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"In Rust, where are local variables of primitive types like i32 or bool stored?","acceptedAnswer":{"@type":"Answer","text":"Local variables of primitive types are stored on the stack. The stack provides very fast allocation and deallocation because it operates on the LIFO (Last In, First Out) principle. Primitive types have a size known at compile time, which allows the compiler to reserve the necessary space on the current function's stack frame."}},{"@type":"Question","name":"Which smart pointer should be used to allocate a value on the heap with a single owner?","acceptedAnswer":{"@type":"Answer","text":"Box is the simplest smart pointer for heap allocation. It guarantees single ownership and automatically frees memory when the Box goes out of scope. Box is useful for types with unknown compile-time size, for large structures that shouldn't be copied on the stack, or for recursive types."}},{"@type":"Question","name":"What is the RAII (Resource Acquisition Is Initialization) pattern in Rust?","acceptedAnswer":{"@type":"Answer","text":"RAII is a pattern where resources (memory, files, connections) are acquired during object creation and automatically released upon destruction. In Rust, this is done via the Drop trait which is automatically called when a value goes out of scope. This pattern ensures no resource is forgotten and prevents memory leaks."}},{"@type":"Question","name":"When is the Drop trait automatically called in Rust?","acceptedAnswer":{"@type":"Answer","text":"The Drop trait is automatically called when a value goes out of scope (end of block, function return, reassignment). Destruction order follows reverse declaration order (LIFO). The compiler automatically inserts drop() calls, so manual calling is never needed. To force early destruction, use std::mem::drop()."}},{"@type":"Question","name":"How can a memory leak be created with Rc in Rust?","acceptedAnswer":{"@type":"Answer","text":"A memory leak can occur with Rc by creating reference cycles. If A contains an Rc to B and B contains an Rc to A, the reference count will never reach zero even if no external variable references the cycle anymore. To prevent this, use Weak to break the cycle by creating a non-owning reference."}},{"@type":"Question","name":"What is the role of Weak in managing reference cycles?","acceptedAnswer":{"@type":"Answer","text":"Weak creates a non-owning reference to a value managed by Rc or Arc. Unlike Rc, Weak doesn't increment the strong count and doesn't prevent the value's destruction. To access the value, call upgrade() which returns Option>. This allows breaking cycles while keeping an observable reference."}},{"@type":"Question","name":"What does Pin guarantee in Rust?","acceptedAnswer":{"@type":"Answer","text":"Pin guarantees that a value won't be moved in memory once pinned. This is crucial for self-referential types (containing pointers to themselves), like Futures generated by async/await. Without Pin, a move would invalidate these internal pointers. Pin doesn't guarantee immutability, only absence of movement."}},{"@type":"Question","name":"What is the main difference between the global allocator and a custom allocator in Rust?","acceptedAnswer":{"@type":"Answer","text":"The global allocator (default jemalloc or system) is used for all heap allocations in the program. A custom allocator allows optimization for specific cases: arena allocators for grouped allocations, bump allocators for fast sequential allocations, or allocators with tracking for debugging. Since Rust 1.28, a global allocator can be defined via #[global_allocator]."}},{"@type":"Question","name":"What does std::mem::drop() do and when is it useful?","acceptedAnswer":{"@type":"Answer","text":"std::mem::drop() takes ownership of a value and destroys it immediately, calling its Drop implementation if it has one. It's useful for releasing resources before the natural end of scope, for example releasing a Mutex lock before function end, or releasing a connection as soon as it's no longer needed to optimize resource usage."}},{"@type":"Question","name":"What does std::mem::forget() do and what risk does its use present?","acceptedAnswer":{"@type":"Answer","text":"std::mem::forget() takes ownership of a value and forgets it without calling its Drop destructor. The memory is never freed, potentially causing a leak. It's sometimes necessary in unsafe Rust or FFI to transfer ownership to external code. Using forget isn't unsafe, but can cause resource leaks if misused."}},{"@type":"Question","name":"How does memory alignment work in Rust?","acceptedAnswer":{"@type":"Answer","text":"Each type in Rust has an alignment that determines valid memory addresses for storing it. Alignment is typically the size of the largest primitive field. The compiler may add padding between struct fields to respect alignment. #[repr(C)] forces C-compatible layout, while #[repr(packed)] removes padding but may degrade performance."}},{"@type":"Question","name":"What problem does the Unpin trait solve in relation to Pin?","acceptedAnswer":{"@type":"Answer","text":"Unpin is an auto-implemented marker trait for types that can be moved even when pinned. Most types are Unpin by default. !Unpin types (like Futures generated by async) cannot be moved after being pinned. This allows Pin to be a no-op for standard types while protecting self-referential types."}},{"@type":"Question","name":"How to create a Pin> for a value that needs to be pinned on the heap?","acceptedAnswer":{"@type":"Answer","text":"To pin a value on the heap, use Box::pin(value) which directly returns a Pin>. This guarantees the value will never be moved because it's heap-allocated and Pin prevents obtaining a mutable reference that would allow std::mem::swap(). This is the standard method for Futures and self-referential types."}},{"@type":"Question","name":"What is the difference between std::mem::size_of::() and std::mem::size_of_val(&v)?","acceptedAnswer":{"@type":"Answer","text":"size_of::() returns the size in bytes of a type known at compile time (static). size_of_val(&v) returns the size of a particular value, useful for dynamically sized types (DST) like slices or trait objects. For a slice, size_of_val returns the total size of elements, not the fat pointer size."}},{"@type":"Question","name":"Why is it impossible to implement both Drop and Copy for the same type?","acceptedAnswer":{"@type":"Answer","text":"Copy indicates a type can be duplicated by simple bit copy (memcpy), without special logic. Drop indicates a type needs cleanup logic at destruction. If a type were Copy with Drop, each copy would have its own destruction, causing double-free or other issues. This is a fundamental invariant of Rust's type system."}},{"@type":"Question","name":"What is an arena allocator and when to use it in Rust?","acceptedAnswer":{"@type":"Answer","text":"An arena allocator allocates objects in a large pre-allocated memory zone and frees them all in a single operation. It's very efficient for temporary allocations in a computation phase (parsing, compilation). Crates like bumpalo or typed-arena provide implementations. Ideal when many small allocations share the same lifetime."}},{"@type":"Question","name":"How does ManuallyDrop allow manual control over destruction?","acceptedAnswer":{"@type":"Answer","text":"ManuallyDrop is a wrapper that prevents automatic Drop destructor calls. The value remains valid but won't be automatically destroyed at scope exit. To destroy it, use ManuallyDrop::drop(&mut val) which is unsafe. Useful in unsafe Rust to precisely control when and if a value is destroyed, especially in FFI."}},{"@type":"Question","name":"What is the memory size of an empty Vec on the stack (not counting the heap buffer)?","acceptedAnswer":{"@type":"Answer","text":"A Vec on the stack contains three pointer-sized values: a pointer to the heap buffer, current length (len), and capacity. On 64-bit architecture, this is 3 x 8 = 24 bytes. An empty Vec has a dangling (but valid and aligned) pointer, len=0 and capacity=0, so no heap allocation is made."}},{"@type":"Question","name":"How does niche-filling optimization work for Option>?","acceptedAnswer":{"@type":"Answer","text":"Niche-filling uses invalid values of a type to represent None without memory overhead. NonNull guarantees the pointer is never null, so null can represent None. Thus Option> has the same size as NonNull. This optimization also applies to Box, Rc, Arc, references, and enums with unused discriminant."}},{"@type":"Question","name":"What is the impact of #[repr(C)] on a struct's memory layout?","acceptedAnswer":{"@type":"Answer","text":"#[repr(C)] forces C-compatible memory layout: fields are ordered exactly as declared, with minimal padding required for alignment. Without this attribute, Rust may reorder fields to optimize size. #[repr(C)] is essential for FFI with C code, for memory-shared structures, or to guarantee deterministic layout."}}]}