DEV Community: SomeB1oody

[Advanced Rust] 2.1. API Design Principles of Unsurprising - Naming Tips, Implementing Common Traits

SomeB1oody — Sat, 01 Aug 2026 17:01:22 +0000

Full title: [Advanced Rust] 2.1. API Design Principles of Unsurprising - Naming Tips, Implementing Common Traits (Debug, Send, Sync, and Unpin)

2.1.1. What Is the Unsurprising Principle?

The unsurprising principle is also called the least-surprise principle. It means that the APIs you write should be as intuitive as possible.

Users should be able to guess what an interface does just by looking at it. At the very least, your interface should not surprise them. Its core idea is to stay close to what users already know, so they do not need to relearn concepts. For example, if an interface name contains error, users will probably guess that it is used for error handling.

In other words, we need our interfaces to be predictable, which requires attention to the following:

Naming
Implementing common traits
Ergonomic traits
Wrapper types

2.1.2. Naming Tips

Interface names should follow conventions so their behavior is easy to infer. Here, conventions means the conventions commonly used in the Rust standard library and Rust community.

Examples:

A method named iter (or ending with iter) will most likely take &self as an argument and return an iterator
A method named into_inner will most likely take self as an argument and return the wrapped type
A type named SomethingError should implement std::error::Error and appear in various Result types

Using the same common names for the same purposes helps users understand the API. This leads to another conclusion: things with the same name should behave in the same way, otherwise users will probably write incorrect code.

2.1.3. Implementing Common Traits

Users usually assume that everything in an interface works “as expected,” for example:

You can print any type with {:?}
You can send anything to another thread
Every type is Clone

So when writing code, actively implement most standard traits, even if you do not need them immediately.

From another angle, users cannot implement foreign traits for foreign types themselves because that would violate the orphan rule. That makes it hard for them to add the traits they want to your types. So you should actively implement most standard traits, so your types can satisfy the traits most users expect.

2.1.4. It Is Recommended to Implement the `Debug` Trait

Almost all types can and should implement the Debug trait.

The simplest and best way is to use #[derive(Debug)]. Note that a derived trait will add the same bound to any generic parameter.

An example makes this clear:

use std::fmt::Debug;

#[derive(Debug)]
struct Pair<T> {
    a: T,
    b: T,
}

fn main() {
    let pair = Pair { a: 5, b: 10 };
    println!("{:?}", pair);
}

The Pair struct implements the Debug trait through derive, so it automatically adds the bound T: Debug to the generic parameter T
The type of the Pair fields in main is i32, which implements Debug, so it can be printed

Output:

Pair { a: 5, b: 10 }

What if I change the field type to something that does not implement Debug?

use std::fmt::Debug;

struct Person {
    name: String,
}

#[derive(Debug)]
struct Pair<T> {
    a: T,
    b: T,
}

fn main() {
    let pair = Pair {
        a: Person { name: "Dave".to_string() },
        b: Person { name: "Nick".to_string() },
    };
    println!("{:?}", pair);
}

Output:

error[E0277]: `Person` doesn't implement `Debug`
  --> src/main.rs:18:22
   |
18 |     println!("{:?}", pair);
   |               ----   ^^^^ `Person` cannot be formatted using `{:?}` because it doesn't implement `Debug`
   |               |
   |               required by this formatting parameter
   |
   = help: the trait `Debug` is not implemented for `Person`
   = note: add `#[derive(Debug)]` to `Person` or manually `impl Debug for Person`
help: the trait `Debug` is implemented for `Pair<T>`
  --> src/main.rs:7:10
   |
 7 | #[derive(Debug)]
   |          ^^^^^
note: required for `Pair<Person>` to implement `Debug`
  --> src/main.rs:8:8
   |
 7 | #[derive(Debug)]
   |          ----- in this derive macro expansion
 8 | struct Pair<T> {
   |        ^^^^ - type parameter would need to implement `Debug`
   = help: consider manually implementing `Debug` to avoid undesired bounds
help: consider annotating `Person` with `#[derive(Debug)]`
   |
 3 + #[derive(Debug)]
 4 | struct Person {
   |

We can also manually implement Debug by using the various debug_xxx helper methods provided by fmt::Formatter in the standard library:

debug_struct
debug_tuple
debug_list
debug_set
debug_map

Example:

use std::fmt;

struct Pair<T> {
    a: T,
    b: T,
}

impl<T: fmt::Debug> fmt::Debug for Pair<T> {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        f.debug_struct("Pair")
            .field("a", &self.a)
            .field("b", &self.b)
            .finish()
    }
}

fn main() {
    let pair = Pair { a: 1, b: 2 };
    println!("{:?}", pair);
}

We manually implement the Debug trait instead of using #[derive(Debug)]
fmt is the method that must be defined when implementing fmt::Debug
f: &mut fmt::Formatter<'_> provides the formatting context and tools
f.debug_struct("Pair") declares that the value should be formatted as a debug struct with fields, and sets the struct name to "Pair"
.field("a", &self.a) and .field("b", &self.b) add the a and b fields to Pair and associate each field with its value
.finish() completes the formatting builder and returns the result to be printed

Output:

Pair { a: 1, b: 2 }

2.1.5. It Is Recommended to Implement the `Send`, `Unpin`, and `Sync` Traits

If your type does not implement Send, it cannot be moved to another thread (for example, thread::spawn requires T: Send). Wrapping a !Send value in Mutex<T> does not help either: Mutex<T> is only Send/Sync when T: Send, so it still cannot be shared across threads.

Example:

use std::rc::Rc;

fn main() {
    let x = Rc::new(42);

    std::thread::spawn(move || {
        println!("{:?}", x);
    });
}

Rc<T> does not implement Send, so it cannot be used across threads

We can write a simple tuple struct ourselves to implement it manually (of course, it will not have Rc<T>'s reference counting feature):

#[derive(Debug)]
struct MyBox(*mut u8);

unsafe impl Send for MyBox {}

fn main() {
    let mb = MyBox(Box::into_raw(Box::new(42)));

    std::thread::spawn(move || {
        println!("{:?}", mb);
    });
}

MyBox implements Send, so it can be used across threads
Traits such as Send that act only as markers and do not provide concrete behavior are called marker traits. Marker traits provide compile-time information but do not add behavior. So implementing Send for MyBox does not require any method body
Manually implementing Send is unsafe, so we must add the unsafe marker before the impl block. Rust's type system normally infers Send automatically to ensure thread safety, while a manual Send implementation may bypass Rust's safety checks

Types that do not implement Sync cannot be shared across threads through Arc<T> (the atomic reference-counted pointer, the multithreaded version of Rc<T>), and they also cannot be stored in static items that require Sync.

Example:

use std::cell::RefCell;
use std::sync::Arc;

fn main() {
    let x = Arc::new(RefCell::new(42));
    std::thread::spawn(move || {
        let mut x = x.borrow_mut();
        *x += 1;
    });
}

RefCell<T> does not implement Sync, so it cannot be shared across threads with Arc<T>

Unpin means “can be unpinned.” It is a marker trait used to indicate whether a type can be safely moved out of a Pin, that is, whether it can bypass the restrictions of Pin<P>.

Most types are Unpin by default. Self-referential types are usually made !Unpin by embedding a marker such as std::marker::PhantomPinned (or another !Unpin field). Rust does not automatically treat “has a self-reference” as !Unpin; without such a marker, the type would still be Unpin, and moving it could invalidate internal pointers.

If your type does not implement any of the above traits, it is recommended that you state that in the documentation.

[Advanced Rust] 1.17. Orphan Rules, Coherence, and Consistency - Blanket and Covered Implementations

SomeB1oody — Sat, 01 Aug 2026 05:25:42 +0000

1.17.1. Coherence

Coherence means that for a given type and method, there is only one correct choice for the implementation of that method on that type.

The orphan rule means that as long as either the trait or the type is in the local crate, you can implement that trait for that type. For example:

A type you define locally can implement the Debug trait
You can implement a trait you define locally for bool
You cannot implement Debug for bool, because neither side is local

There are exceptions to the orphan rule, which we will discuss below.

1.17.2. Blanket Implementation

A blanket implementation, also called a general implementation, means that Rust allows a default implementation for every type that satisfies a trait bound.

Its template is:

impl<T> MyTrait for T where T: ...

This means implementing MyTrait for all types that implement some trait.

For example:

impl<T: Display> ToString for T {}

This means implementing ToString for all types that implement Display.

This example is not yet written in template form. In template form, it would be:

impl<T> ToString for T where T: Display {}

Note that only the crate that defines the trait is allowed to use blanket implementations. Adding a blanket implementation to an existing trait is a breaking change.

1.17.3. Fundamental Types

Some types are so fundamental that we need to allow anyone to implement traits for them, even if that would violate the orphan rule. These types are marked #[fundamental], and currently include &T, &mut T, Box<T>, and Pin<P>.

One extra note: the main purpose of Pin<P> is to ensure that a value cannot be moved, that is, to prevent operations such as std::mem::replace, std::mem::swap, or std::mem::take from changing the value’s physical address
For the purpose of the orphan rule, these types are actually erased before orphan-rule checking takes place

Note: using blanket implementations on fundamental types is also considered a breaking change.

1.17.4. Covered Implementation

Sometimes you need to implement an external trait for an external type, which is called a covered implementation. This uses one narrow exemption established by the orphan rule: it allows an external trait to be implemented for an external type in very specific cases.

Note: covered implementation can refer either to Covered Implementation or Override Implementation. Here it refers to Covered Implementation. Override implementation means that when a struct implements a trait and provides its own methods, it can override the default implementation.

The template for this form is:

impl<P1..=Pn> ForeignTrait<T1..=Tn> for T0

P1..=Pn and T1..=T0 refer to a number of parameters

This form is allowed only if all of the following conditions are met:

At least one of T1..=Tn is a local type
No T (where T is one of the generic types in P1..=Pn) may appear before the first such local type
A generic type parameter P may appear in T0..Ti as long as it is wrapped by some intermediate type
- If T appears as a type parameter of another type, such as Vec<T>, then T is considered wrapped
- If T appears only by itself, or behind a fundamental type such as &T, then it is not wrapped

For a simple example:

impl From<MyType> for Vec<i32>

This implements the external From<MyType> trait for the external Vec<i32> type.

Here are some more complex examples. You can use the rules above to understand them:

Implementation	Valid?
`impl<T> From<T> for MyType`	OK
`impl<T> From<T> for MyType<T>`	OK
`impl<T> From<MyType> for Vec<T>`	OK
`impl<T> ForeignTrait<MyType, T> for Vec<T>`	OK
`--------------------------------------------`	------------
`impl<T> ForeignTrait for T`	Not OK
`impl<T> From<T> for T`	Not OK
`impl<T> From<Vec<T>> for T`	Not OK
`impl<T> From<MyType<T>> for T`	Not OK
`impl<T> From<T> for Vec<T>`	Not OK
`impl<T> ForeignTrait<T, MyType> for Vec<T>`	Not OK

Whether a covered implementation is a breaking change depends on the specific situation:

Adding a new implementation to an existing trait, with at least one new local type that satisfies the conditions above, is a non-breaking change
Adding an implementation for an existing trait that does not meet the conditions above is a breaking change

Note:

impl<T> ForeignTrait<MyType, T> for Vec<T> is valid
impl<T> ForeignTrait<T, MyType> for Vec<T> is invalid

[Advanced Rust] 1.16. Generic Traits - Generic (Type-Parameter) Traits and Associated-Type Traits

SomeB1oody — Sat, 01 Aug 2026 05:11:39 +0000

1.16.1. Two Ways to Make a Trait Generic

Traits can be generic in two ways:

Generic type parameters. Example: trait Foo<T>
Associated types. Example: trait Foo { type Bar; }

The difference between the two is:

With associated types, a given trait for a specific type has only one implementation
With generic parameters, there can be multiple implementations

A simple suggestion: if possible, prefer associated types.

1.16.2. Generic (Type-Parameter) Traits

Generic traits require you to specify all generic type parameters and repeat their bounds.

This is somewhat harder to maintain. For example, if you add a generic type parameter to a trait, all implementers of that trait must update their code.

This form can also lead to the problem that a trait may have multiple implementations for a given type. Then the compiler has a harder time inferring which instance of the trait you actually want. Sometimes you must call an ambiguity-resolving function such as FromIterator::<u32>::from_iter.

In some cases this feature is also an advantage, for example:

impl PartialEq<BookFormat> for Book, where BookFormat can be different types
You can implement both FromIterator<T> and FromIterator<&T> where T: Clone

1.16.3. Associated-Type Traits

Let’s use a piece of code as an example:

trait Contains {
    type A;
    type B;

    // Updates syntax to refer to these new types generically
    fn contains(&self, _: &Self::A, _: &Self::B) -> bool;
}

With associated types:

The compiler only needs to know the type that implements the trait
The bound can live entirely on the trait itself and does not need to be repeated
Adding another associated type in the future does not affect users
The concrete type determines the associated types inside the trait, so there is no need to use ambiguity-resolving functions. Look at this example:

impl Contains for Container {
    // Specify what types `A` and `B` are. If the `input` type
    // is `Container(i32, i32)`, the `output` types are determined
    // as `i32` and `i32`.
    type A = i32;
    type B = i32;

    // `&Self::A` and `&Self::B` are also valid here.
    fn contains(&self, number_1: &i32, number_2: &i32) -> bool {
        (&self.0 == number_1) && (&self.1 == number_2)
    }

    // Grab the first number.
    fn first(&self) -> i32 { self.0 }

    // Grab the last number.
    fn last(&self) -> i32 { self.1 }
}

This example implements the Contains trait for the Container type
The associated types in Container’s Contains implementation are determined by type A = i32; and type B = i32;

You Cannot Implement `Deref` for Multiple Target Types

Look at the source code of the Deref trait:

pub trait Deref {
    type Target: ?Sized;

    fn deref(&self) -> &Self::Target;
}

Target in type Target: ?Sized; is the target type we are talking about

Let’s write a Deref implementation to illustrate:

use std::ops::Deref;

struct Wrapper {
    value: String,
}

impl Deref for Wrapper {
    type Target = String;

    fn deref(&self) -> &Self::Target {
        &self.value
    }
}

In the code above, Wrapper can only be dereferenced as String. But if you want Wrapper to be dereferenced as both String and str at the same time, Rust does not allow you to implement Deref again, because Target can only have one concrete type.

In other words, this is illegal:

use std::ops::Deref;

struct Wrapper {
    value: String,
}

// First Deref implementation, Target = String
impl Deref for Wrapper {
    type Target = String;

    fn deref(&self) -> &Self::Target {
        &self.value
    }
}

// This is illegal: Rust does not allow a second `Deref` implementation
// for the same `Wrapper` type.
impl Deref for Wrapper {
    type Target = str;  // Conflict: Rust cannot infer which `Target` applies

    fn deref(&self) -> &Self::Target {
        &self.value
    }
}

You Cannot Use Multiple `Item`s to Implement the `Iterator` Trait

The reason is the same as the reason you cannot implement Deref for multiple target types: it mainly involves the uniqueness of associated types and the inference rules of the Rust compiler.

[Advanced Rust] 1.15. Trait Bounds - Compilation and Dispatch

SomeB1oody — Thu, 30 Jul 2026 16:14:29 +0000

1.15.1. Static Dispatch

What happens when we compile generic code?

The compiler copies part of the type or function for each T (for each concrete type), so that each type has its own function. This process is called monomorphization. (Calling methods on a dyn Trait is different: that uses dynamic dispatch, covered later in this article.)

When you build Vec<i32> or HashMap<String, bool>, the compiler copies the generic type and all of its implementation blocks. For example, Vec<i32> replaces the T in Vec<T> with i32, effectively making a full copy of Vec, with every T replaced by i32.

In other words, the compiler replaces the generic parameters of an instance with concrete types. Note that the compiler does not literally duplicate and paste everything; it only copies the code you actually use.

Look at this example:

impl String {
    pub fn contains(&self, p: impl Pattern) -> bool {
        p.is_contained_in(self);
    }
}

This example implements a contains method for String
The second parameter p of contains is constrained by Pattern. p has no concrete type of its own, only a trait bound, so p is effectively a generic parameter

When p is used in practice, it may be different types. The method is copied for each concrete type, because we need to know the address of is_contained_in so that it can be called. The CPU needs to know where to jump and continue execution.

For any given p, the compiler knows that the address belongs to a method implementation for the Pattern trait. There is no universal address that works for any type.

PS: I know you may be thinking of Python’s dynamic typing, but in Python a variable is fundamentally a **reference* to an object, not a value stored directly.*

Because of this, the compiler needs to produce one copy of the method body for each type, and each copy has its own address for jumping to. That is called static dispatch, because for any given copy of the method, the address we “dispatch to” is known statically.

Static in programming usually refers to things known at compile time, or things that can be treated as such

1.15.2. Monomorphization

Monomorphization means the process of turning one generic type into many non-generic types. Rust traits have this property.

After the compiler finishes optimizing the code, it is as if there were no generics at all. Each instance is optimized separately with all known types, so the is_contained_in call in the example above runs just as efficiently as if the trait did not exist at all — there is no performance loss.

The compiler fully understands the types involved, and in the appropriate cases, it can even inline them.

“Fully understands the types involved” means Rust is a statically typed language, so the types of all variables and functions can be determined at compile time, without type inference at run time.
“Inline them” means expanding the function body directly at the call site to avoid function-call overhead.

#[inline(always)]
fn add(a: i32, b: i32) -> i32 {
    a + b
}

fn main() {
    let x = add(2, 3);  // The compiler may optimize this into `let x = 2 + 3;`
}

1.15.3. The Cost of Monomorphization

Every instance must be compiled separately, which increases compilation time if the compiler cannot optimize it away
Each monomorphized function has its own machine code, which makes the program larger
Instructions cannot be shared across different instances of a generic method, so CPU instruction-cache efficiency drops because it must hold multiple copies of the same instruction

1.15.4. Dynamic Dispatch

Dynamic dispatch allows code to call trait methods on a generic type without knowing the concrete type.

We can make a small change to the code above to achieve dynamic dispatch:

impl String {
    pub fn contains(&self, p: &dyn Pattern) -> bool {
        p.is_contained_in(self);
    }
}

In this example, dynamic dispatch requires the caller to provide two pieces of information:

The data pointer for Pattern
The address of is_contained_in

Why does impl Pattern need & in front of it?

Dynamic dispatch depends on a trait object, and a trait object is essentially a wide pointer (a fat pointer, as discussed in the previous article), so the data must be passed by reference (because Rust cannot know the memory size of the dynamic dispatch type, it can only use a reference)

1.15.5. Vtable

In practice, the caller provides a pointer to a block of memory called a virtual method table, or vtable for short.

In the example above, it holds the addresses of all trait-method implementations for that type, including the address of is_contained_in.

When the code wants to call a trait method on the provided type, it looks up the implementation address of is_contained_in in the vtable and calls it. This lets us use the same function body without caring which type the caller wants to use.

Each vtable also includes layout and alignment information for the concrete type, which is always needed together with the method information.

1.15.6. Object Safety

The combination of a type implementing a trait and its vtable forms a trait object.

Most traits can be turned into trait objects, but not all. For example, Clone cannot (clone returns Self), and Extend cannot either. These examples are not object-safe.

The specific requirements for object safety are:

Trait methods must not be generic, and they must use a receiver that can be dispatched through a trait object
The trait cannot have static methods, because there is no instance on which to call them

1.15.7. `self: Sized`

self: Sized means self cannot be used on a trait object, because trait objects are !Sized.

Using self: Sized on a trait means that dynamic dispatch should never be used.

We can also use self: Sized on a specific method. In that case, the method becomes unavailable when the trait is accessed through a trait object.

When checking whether a trait object is safe, methods marked with where Self: Sized are exempt.

1.15.8. Pros and Cons of Dynamic Dispatch

Advantages	Disadvantages
Shorter compilation time	The compiler cannot optimize for a specific type
Better CPU instruction-cache efficiency	Functions can only be called through the vtable
	Method calls have extra overhead
	Every method call on a trait object must look up the vtable

1.15.9. How to Choose Between Static and Dynamic Dispatch

Static Dispatch	Dynamic Dispatch
Use static dispatch in libraries	Use dynamic dispatch in binaries
You cannot know the user’s needs	A binary is the final code
If dynamic dispatch is used, the user is stuck with it	Dynamic dispatch keeps the code cleaner by removing generic parameters
If static dispatch is used, the user can choose for themselves	Compiles faster
	At the cost of marginal performance

[Advanced Rust] 1.14. Memory Types Pt.2 - Dynamically Sized Types and Wide Pointers, Packed Layouts, Larger Alignment for Speci…

SomeB1oody — Thu, 30 Jul 2026 06:16:11 +0000

Full title: [Advanced Rust] 1.14. Memory Types Pt.2 - Dynamically Sized Types and Wide Pointers, Packed Layouts, Larger Alignment for Specific Fields or Types, Memory Representation of Complex Types, and Repr Rust

1.14.1. `repr(Rust)`

Remember the example in the previous article? That example used repr(C), and the limitation of the C representation is that all fields must be placed in the same order as they are defined in the original struct.

repr(Rust) is the default representation. It intentionally provides fewer layout guarantees than repr(C): the compiler may reorder fields, and two types with the same fields in the same order are still not guaranteed to share a layout.

Because the compiler may reorder fields (for example, placing larger fields first), padding can often be reduced. In the Foo example from the previous article, one possible optimized layout needs no padding.

With fewer guarantees about layout, the compiler has room to rearrange things and produce efficient code.

If repr(Rust) is used, then one possible memory layout of the Foo struct from above is:

Code	Field Type Size	Default Representation	Final Alignment
`#[repr(Rust)]`
`struct Foo {`
`long: u64,`	8 bytes	8-byte aligned	8 bytes
`normal: u32,`	4 bytes	4-byte aligned
`short: u16,`	2 bytes	2-byte aligned
`small: u8,`	1 byte	1-byte aligned
`tiny: bool,`	1 byte	1-byte aligned
`}`
Total 16 bytes

The compiler first orders the fields by size, putting the largest first so that it can determine what alignment the struct should use. In this example, u64 is the largest and takes 8 bytes, so the struct is aligned to 8 bytes
The compiler then looks at the remaining fields and sees that their total size is exactly 8 bytes, so it can place them together and avoid padding
In the end, this struct only needs 16 bytes, which saves half the memory compared with repr(C)
This is more efficient, but compilation time may be a little longer

1.14.2. Packed Layouts

You can tell the compiler that no padding is needed between fields, but then you must accept the performance cost of misaligned access.

When memory is limited or when there are many instances of a type, a packed layout can be useful. It is also useful when sending a memory representation over a low-bandwidth network connection.

To enable a packed layout, add the #[repr(packed)] annotation to the type.

Note that with a packed layout:

Code may run more slowly
In extreme cases, if the CPU supports only aligned access, the program may crash

1.14.3. Giving a Specific Field or Type a Larger Alignment

Using the #[repr(align(n))] annotation lets you give a specific field or type a larger alignment, where n is the argument.

For example, if you want to ensure that different values stored contiguously in memory (like in an array) end up on different CPU cache lines, you can avoid false sharing.

Here is a brief explanation of the related terms:

Cache is composed of cache lines, and caches operate on cache lines as units. A cache line is the smallest data unit that can be mapped into the cache
False sharing happens when two different CPUs access different variables that share the same cache line. In theory they could operate in parallel, but in the end they are both competing to update the same cache entry. This can cause a huge performance drop in concurrent programs

1.14.4. Memory Representation of Complex Types

Tuples: Their memory representation is like a struct; the field types and tuple element types are in the same order
Arrays: A contiguous sequence of the contained type, with no padding between elements
Unions: For each field, the layout choice is independent; the alignment is the maximum among all fields
Enums: Like unions, but with an additional hidden shared field used to store the discriminant of the enum variant. The code uses the discriminant value to determine which variant a given value contains. The size of the discriminant depends on the number of variants

1.14.5. Dynamically Sized Types and Wide Pointers

Most types in Rust automatically implement the Sized trait.

Rust needs to know some details about its types, such as how much space to allocate for a value of a specific type. That is what makes the concept of dynamically sized types a little confusing. They are sometimes called DSTs or unsized types, and they let us write code that works with values whose size is only known at run time.

To use dynamically sized types, Rust provides the Sized trait to indicate whether the size of a type is known at compile time. Everything whose size is known at compile time automatically implements this trait. Rust also implicitly adds the Sized trait to every generic function. By default, generic functions apply only to types whose size is known at compile time. This restriction can be relaxed with ?Sized. ?Sized means “T may or may not implement Sized,” that is, T may or may not be a dynamically sized type. This notation does not require the default condition that generic types must have a known size at compile time. The ?Trait syntax with this meaning applies only to the Sized trait and no other trait.

What should we do when a function needs to accept a DST — such as a trait object or a slice — as a parameter? We can use a wide pointer (also called a fat pointer).

1.14.6. Wide Pointers

By placing a non-Sized type behind a wide pointer, we bridge the gap between Sized and non-Sized types.

So what exactly is a wide pointer? A wide pointer is an ordinary pointer with an additional "word-size" field attached. It provides the compiler with the extra information it needs about the pointer so that it can generate sensible code that uses that pointer.

When you reference a DST, the compiler automatically constructs a wide pointer for you. For example, the extra information for a slice is the slice’s length.

Wide pointers are Sized because they are pointers at heart, and their size is fixed (twice the size of a “sized” pointer — one field stores the pointer itself, and the other stores the attached metadata used to “complete” the type).

Note: Box<T> and Arc<T> both support storing wide pointers, so they both support ?Sized.

[Advanced Rust] 1.13. Memory Types Pt.1 - Alignment, Layout, and the Repr Attribute

SomeB1oody — Tue, 28 Jul 2026 18:34:11 +0000

1.13.1. The Basic Responsibility of Types

Every Rust value has a type, and the responsibility of that type is to tell you how to interpret the bits in memory.

For example, the bit pattern 0b10111101 has no meaning by itself, but:

Interpreted as u8, it becomes the number 189
Interpreted as i8, it becomes the number -67

When you define a custom type, the compiler decides where each part of that type is placed in memory.

1.13.2. Alignment

Alignment determines where a type’s bytes may be stored.

Once a type’s representation is determined, you might think it can be stored anywhere in memory. In theory that is possible, but in practice computer hardware places constraints on where a given type can live.

The most typical example is a pointer. A pointer points to bytes, not bits; one byte equals 8 bits. In other words, it does not point to an individual bit. So if a value of some type were placed at bit index 4 in memory, you would not be able to address it, because pointers address bytes rather than specific bits. That is why alignment is done at the byte level — that is, at 8-bit boundaries.

For this reason, all values, regardless of type, must begin on a byte boundary. All types must be at least byte-aligned. In other words, the storage address must be a multiple of 8 bits.

1.13.3. Stricter Alignment Rules

Some types have alignment requirements stricter than byte alignment. In CPU and memory systems, memory is often accessed in blocks larger than a single byte.

For example, on a 64-bit CPU, most values are accessed in 8-byte blocks, and each operation begins at an address that is 8-byte aligned. This is also called the CPU word size.

Of course, CPUs can also handle reads and writes of smaller values, as well as values that cross block boundaries. But as developers, we should try our best to ensure that hardware operates at its native alignment.

For example, if the i64 value you want to read begins in the middle of an 8-byte block, then reading it requires at least two reads. Because i64 is 8 bytes wide, beginning in the middle of two 8-byte blocks means it must span both blocks. So when reading it, the engine must read from both blocks: the first block provides the first part of the i64, the second block provides the remaining part, and then the pieces must be merged.

That is very inefficient and slows down program execution, so we should try to keep hardware operations aligned to their native boundaries whenever possible.

1.13.4. Misaligned Access

When a CPU accesses memory and the data address does not follow the alignment required by the architecture, it is called a "misaligned access". This can lead to poor performance and concurrency issues.

Many CPUs require, or strongly recommend, that their parameters be naturally aligned. A naturally aligned value has alignment that matches its size.

For example, if you want to load 8 bytes, the provided address should be 8-byte aligned.

1.13.5. The Compiler Tries to Use Alignment as Much as Possible

Based on the contents a type includes, the compiler computes an alignment for that type (or, in other words, assigns it an alignment scheme):

For primitive values, alignment usually matches their size. For example, u8 is aligned to 1 byte, u16 to 2 bytes, u32 to 4 bytes, and u64 to 8 bytes.
For compound types (types that contain other types), the alignment is usually the maximum alignment of the contained types. For example, if a type contains fields of u8, u16, and u32, then the type should be 4-byte aligned (u32 has the largest alignment, which is 4 bytes).

1.13.6. Layout

The layout of a type is how the compiler decides to represent that type in memory.

The Rust compiler does not provide many guarantees about how types are laid out.

Rust provides the repr attribute: it can be added to a type definition to request a specific representation.

1.13.7. `repr(C)`

One of the most common repr attributes is repr(C). The C in the name indicates that it is related to C.

repr(C) layout is compatible with the layout used by C/C++ compilers for the same type. This is useful for Rust code that interacts with other languages through FFI (Foreign Function Interface).

When using FFI to interact with other languages, Rust generates a layout that matches what the other language’s compiler expects. Because C layout is predictable and unlikely to change, repr(C) is very useful in unsafe contexts.

For example, you can use it when working with raw pointers to that type or when converting between two types with the same fields.

1.13.8. `repr(transparent)`

The transparent in repr(transparent) means transparent. It is used on newtype-style wrappers and guarantees that the outer type has the same layout as its single non-zero-sized field. (Other fields are allowed only if they are zero-sized types, such as () or PhantomData.)

This is very useful when combined with the newtype pattern.

Let’s briefly revisit the newtype pattern here: you use a tuple struct to create a new local type, which is essentially a thin wrapper.

For example, if you want to operate on the memory representation of struct A and struct NewA(A), then after using repr(transparent), the two memory representations should be the same. Without it, the Rust compiler cannot guarantee that.

1.13.9. An Example of Using `repr`

Let’s look at an example:

Code	Field Type Size	Default Representation	Padding	Final Alignment
`#[repr(C)]`
`struct Foo {`
`tiny: bool,`	1 byte	1-byte aligned	3 bytes
`normal: u32,`	4 bytes	4-byte aligned		(`tiny` + `normal`) 8 bytes
`small: u8,`	1 byte	1-byte aligned	7 bytes	8 bytes
`long: u64,`	8 bytes	8-byte aligned		8 bytes
`short: u16,`	2 bytes	2-byte aligned	6 bytes	8 bytes
`}`
Total 32 bytes

This table shows the memory alignment and padding of a Rust struct under #[repr(C)]:

The code is in the leftmost column and uses the repr(C) annotation. The struct contains several fields
The Rust compiler first sees that the tiny field is of type bool, which occupies 1 byte in memory, so it is aligned to 1 byte
The compiler then sees that the normal field is of type u32, which occupies 4 bytes, so it only needs 4-byte alignment. At this point Rust notices that tiny is aligned to 1 byte, so the compiler inserts 3 bytes of padding to make tiny occupy 4 bytes
Since this field now occupies exactly 8 bytes, which is a multiple of 4 bytes, it is already aligned
The small field is of type u8, which occupies 1 byte and is aligned to 1 byte. Because the previous two fields are already aligned, Rust will decide how much padding to add based on the following bytes. At this point the compiler still has to wait and see
long is of type u64, which occupies 8 bytes and is naturally 8-byte aligned. Since its field is 8 bytes or larger, we now see that tiny and normal together form an 8-byte-aligned region, and long is also 8-byte aligned. Rust understands that the structure should now be aligned to 8 bytes. Therefore the compiler has to add 7 bytes of padding to small to make it 8-byte aligned
short is of type u16, which occupies 2 bytes. Since the structure should now be 8-byte aligned, the compiler adds 6 bytes so that it becomes 8-byte aligned

The process can be represented in a table like this:

Field	Type Size	Required Alignment	Padding	Notes
`tiny: bool`	1 byte	1 byte	3 bytes	To align the next `u32`
`normal: u32`	4 bytes	4 bytes	none	Aligned as `u32`
`small: u8`	1 byte	1 byte	7 bytes	To align the next `u64`
`long: u64`	8 bytes	8 bytes	none	8-byte aligned
`short: u16`	2 bytes	2 bytes	6 bytes	Structure aligned to 8 bytes

[Advanced Rust] 1.12. Lifetimes (Advanced) Pt.2 - Lifetime Variance, Covariance, Invariance, Contravariance

SomeB1oody — Tue, 28 Jul 2026 00:30:07 +0000

1.12.1. Lifetime Variance

Variance is a concept in Rust’s type system. It describes how generic parameters — especially lifetime parameters — relate to one another in the type hierarchy.

We can think of it simply as variance describes which types are “subtypes” of other types, where “subtype” is somewhat similar to the concept used in Java and C#.

In addition, variance also cares about when a “subtype” can replace a “supertype” and vice versa.

In general, if A is a subtype of B, then A is at least as useful as B. Here is a Rust example: if a function takes &'a str, then &'static str can be passed in. Because 'static is a subtype of 'a, 'static lives at least as long as any 'a (and 'static can remain valid for the entire program).

1.12.2. Three Kinds of Lifetime Variance

All types have variance. The variance associated with each type defines which similar types can be used in that type’s position.

Note: the following content is fairly difficult. It is recommended that you first recall the ideas of sufficient conditions and necessary conditions from high school math.

1. Covariant

Covariant means that a type can be replaced only by a “subtype.”

Covariance means:

if A <: B (A is a subtype of B), then F<A> <: F<B> (F<A> is also a subtype of F<B>)

This is a transitive inheritance relationship from smaller to larger, similar to reasoning from a sufficient condition: if A holds, then B must also hold (A is a sufficient condition for B).

For example, &'static T can replace &'a T, because &T is covariant over the lifetime 'a, so 'a can be replaced by one of its subtypes, such as 'static.

2. Invariant

Invariant means that you must provide the exact specified type.

Invariance means:

A <: B cannot imply F<A> <: F<B>, and F<B> <: F<A> also cannot be inferred

This means there is not enough relationship between F<A> and F<B> to derive one from the other, so they are neither sufficient conditions nor necessary conditions; they are independent.

For example, the mutable reference &mut T is invariant over T.

3. Contravariant

Contravariance means:

if A <: B (A is a subtype of B), then F<B> <: F<A> (F<B> is instead a subtype of F<A>)

The logic here is: “To make F<A> hold, B must satisfy A’s condition,” which is more like a necessary condition: if B holds, then A must also hold (A is a necessary condition for B).

You can think of contravariance as “the relationship moves in the opposite direction”: the lower a function’s requirements for its parameters, the greater the range of cases it can handle.

Here are two examples:

Suppose there are two variables, x1 and x2, where x1 has the lifetime 'static and x2 has the lifetime 'a. Then clearly x1 is more useful than x2, because it lives longer.
Suppose there are two functions, take_func1 and take_func2, where take_func1 accepts &'static str and take_func2 accepts &'a str. Clearly, take_func1 places stricter requirements on its argument, which means take_func1 is not as broadly useful as take_func2.

From the two examples above, we can see that giving a variable a longer lifetime makes it more useful, but requiring a function parameter to have a longer lifetime makes the function less useful. That is contravariance.

So what is contravariant with what? It is the function’s contravariance over the types of its parameters.

1.12.3. The Role of Lifetime Variance

Let’s look at an example to see what lifetime variance does:

struct MutStr<'a, 'b> {  
    s: &'a mut &'b str,  
}  

fn main() {  
    let mut s = "hello";  
    *MutStr { s: &mut s }.s = "world";  
    println!("{}", s);  
}

The confusing part of this code is the MutStr struct, so let’s break it down:

The struct has only one field, but it has two lifetimes
&'a mut means a mutable reference, and the lifetime of that mutable reference is 'a
&'b str means a reference to a string slice, and the lifetime of that string slice is 'b
In other words, MutStr lets you store a mutable reference that points to a reference to a string slice. You can modify s itself, but you cannot modify the string content pointed to by &'b str

Next, let’s look at the logic in main:

let mut s = "hello"; declares the variable s, whose type is &str, and whose value is "hello"
*MutStr { s: &mut s }.s = "world"; is actually several steps combined into one line. Let’s separate them:
- MutStr { s: &mut s } passes a mutable reference to s into the MutStr struct. At this point, the value of the s field inside MutStr is "hello"
- In *MutStr { s: &mut s }.s = "world";, the .s means access the s field (at this point the field’s value is &mut s). * dereferences s, that is, it obtains the reference itself to the string slice s. = "world" changes the pointed-to value — s used to point to "hello", and now it is changed to "world", that is, s = "world"

What if there were only one lifetime — could this still be written?

struct MutStr<'a> {  
    s: &'a mut str,  
}  

fn main() {  
    let mut s = "hello";  
    *MutStr { s: &mut s }.s = "world";  
    println!("{}", s);  
}

Output:

error[E0308]: mismatched types
 --> src/main.rs:7:31
  |
7 |     *MutStr { s: &mut s }.s = "world";  
  |     -----------------------   ^^^^^^^ expected `str`, found `&str`
  |     |
  |     expected due to the type of this binding

error[E0277]: the size for values of type `str` cannot be known at compilation time
 --> src/main.rs:7:5
  |
7 |     *MutStr { s: &mut s }.s = "world";  
  |     ^^^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
  |
  = help: the trait `Sized` is not implemented for `str`
  = note: the left-hand-side of an assignment must have a statically known size

On this one-liner, rustc reports the failure at the assignment (expected str, found &str, and str is unsized). The deeper type problem is that &mut s has type &mut &str, while the field expects &mut str.

More specifically:

The variable s has type &str (a reference to a string slice).
When you write &mut s, its actual type is &mut &str, that is, a mutable reference to the variable s. However, the MutStr definition requires the field s to have type &mut str.
If you isolate the construction as MutStr { s: &mut s }, rustc instead reports that you cannot borrow the data behind an & reference as mutable — the same underlying mismatch, surfaced differently.

These are different referent types, not a lifetime-subtyping question. (Separately, note that &mut T does support unsizing coercions such as &mut [T; N] → &mut [T]; that mechanism still cannot turn &mut &str into &mut str.)

What invariance does matter for is the two-lifetime version: &'a mut &'b str is invariant in 'b, which prevents unsoundly shortening the inner borrow when you assign through the mutable reference.

You can also think about it this way:

String literals ("hello" and "world" are string literals) have type &str and an implicit 'static lifetime annotation, which means &str is actually &'static str. In the original struct, this corresponds to 'b
The struct’s 'a corresponds to the lifetime of the mutable reference, which is the lifetime of the &mut mutable reference in the line *MutStr { s: &mut s }.s = "world"
After the change, the struct with only one lifetime parameter expects &mut str, but &mut s still has type &mut &str, so the types do not match

[Advanced Rust] 1.11. Lifetimes (Advanced) Pt.1 - Review, Borrow Checker, Generic Lifetimes

SomeB1oody — Tue, 28 Jul 2026 00:28:57 +0000

1.11.1. Review

In the beginner tutorial, we mentioned that every reference in Rust has a lifetime. A lifetime is the scope in which the reference remains valid, and in most cases it is implicit and inferred by the compiler.

When you take a reference to a variable, the lifetime begins. When the variable is moved or goes out of scope, the lifetime ends. In other words, for a reference, a lifetime is the name of the code region in which it must remain valid.

Lifetimes usually overlap with scopes, but not always.

1.11.2. Borrow Checker

Whenever a reference with some lifetime 'a is used, the borrow checker checks whether 'a is still alive. The process is:

Trace the path back to where 'a began — that is, where the reference was obtained
From there, check whether there are conflicts along that path
Ensure that the reference points to a value that can be accessed safely

This example uses the rand crate. Add the following dependency to Cargo.toml:

[dependencies]
rand = "0.8"

Consider this example:

use rand::random;  

fn main() {  
    let mut x = Box::new(42);  
    let r = &x;  
    if random::<f32>() > 0.5 {  
        *x = 84;  
    } else {  
        println!("{}", r);  
    }  
}

x is of type Box<i32>
Declaring r as a reference to x means the reference’s lifetime begins on that line (line 5)
On line 7, the value of x is modified through dereferencing. That requires a mutable reference to x. At this point, the borrow checker looks for a mutable reference to x and checks whether its use conflicts with anything else. In this example there is no conflict, so the code is valid
You may ask: line 7 is inside the scope of r. Since *x needs a mutable reference to x, shouldn’t having both the immutable reference r and the mutable reference *x in the same scope violate the borrowing rules and produce an error?
In fact, Rust is smart enough to know that if the if branch is taken, the else branch cannot be taken. r is never used in the if branch at all, so using the mutable reference *x in the if branch is fine. In other words, the lifetime of r does not extend into the if branch. This is an example of how lifetimes do not always exactly match scopes.

Let’s look at another example:

fn main() {  
    let mut x = Box::new(42);  

    let mut z = &x;  
    for i in 0..100 {  
        println!("{}", z);  
        x = Box::new(i);  
        z = &x;  
    }  
    println!("{}", z);  
}

x is of type Box<i32>
z is a reference to x, so the lifetime begins on this line (line 4)
On line 6, z is printed inside the loop. Using z naturally triggers a borrow-checker check. There is no problem here, so the borrow checker does not report an error
On line 7, x is reassigned
On line 8, z is reassigned. Rust treats the newly assigned reference as a different reference, so line 8 effectively starts a new lifetime, and the original lifetime ends at line 7
Each subsequent loop iteration starts a new lifetime at z = &x;. Therefore the borrow checker does not report an error

Features of the Borrow Checker

The borrow checker is conservative: if it is not sure whether a borrow is valid, it rejects that borrow.

Sometimes the borrow checker needs help understanding why a borrow is valid, which is one of the reasons Unsafe Rust exists.

1.11.3. Generic Lifetimes

Sometimes we need to store references inside our own types. Then we need to annotate those references with lifetimes so that the borrow checker can verify their validity. One example is returning a reference from a method where the returned reference lives longer than self.

Rust lets you make a type generic over one or more lifetimes.

Two Reminders

If a type implements the Drop trait, then dropping the type counts as using the lifetimes or types that the type is generic over. If the type does not implement Drop, then dropping it does not count as using the lifetime, and the references inside the type can be ignored.
For example, when an instance of some type is about to be dropped, the borrow checker checks whether it is still legal to use the lifetimes that the type is generic over, because the code in your drop function might use those references.
A type can be generic over multiple lifetimes, but usually there is no need to make the type signature more complex. You should use multiple lifetime parameters only when the type contains multiple references, and the returned reference should be tied only to one of those lifetimes.

Look at this example:

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {  
    if x.len() > y.len() {  
        x  
    } else {  
        y  
    }  
}

'a denotes a lifetime called a. x, y, and the return type all share this lifetime a, which means that x, y, and the return value all have the same lifetime.

[Advanced Rust] 1.10. References and Interior Mutability (Quick Recap) - References, Interior Mutability, Cell Type, and Relate…

SomeB1oody — Sat, 25 Jul 2026 20:34:21 +0000

Full title: [Advanced Rust] 1.10. References and Interior Mutability (Quick Recap) - References, Interior Mutability, Cell Type, and Related Operations

1.10.1. References

Through references, Rust allows values to be borrowed without giving up ownership.

A reference is a pointer with an additional contract attached. Rust has two kinds of references.

1. Shared References

Shared references, also called immutable references, are written in Rust as &T, where T stands for a type.

Their characteristic is that any number of references can exist at the same time, or within the same scope, pointing to the same value. Every shared reference implements the Copy trait.

The value behind a shared reference is immutable. The compiler is allowed to assume that the value pointed to by a shared reference does not change while that reference is alive.

For example: if the value behind a shared reference is read multiple times inside a function, the compiler is allowed to read it once and then reuse the read value.

2. Mutable References

The counterpart to immutable references is the mutable reference, written in Rust as &mut T.

A mutable reference is exclusive, which means that within one scope there can be only one mutable reference; there cannot be a second mutable reference or any number of shared references. Therefore, mutable references do not implement the Copy trait (shared references do).

The compiler assumes that no other thread accesses the type pointed to by a mutable reference, whether through a shared reference or another mutable reference.

1.10.2. Owning a Value vs. Owning a Mutable Reference to a Value

The owner is responsible for deleting the value — or dropping it — and aside from that, the two behave mostly the same.

Note: if you move the value behind a mutable reference, you must leave another value in its place. If you do not, the owner will think it still needs to drop the value, but there is actually nothing left to drop, which leads to undefined behavior or a compilation error.

Take a look at this example:

fn main() {
    let mut s = String::from("Hello");
    let r = &mut s;

    let t = *r;  // Try to move the value pointed to by `r`
    println!("{}", r);  // `r` becomes a dangling reference
}

Output:

error[E0507]: cannot move out of `*r` which is behind a mutable reference
 --> src/main.rs:5:13
  |
5 |     let t = *r;  // Try to move the value pointed to by `r`
  |             ^^ move occurs because `*r` has type `String`, which does not implement the `Copy` trait
  |
help: consider removing the dereference here
  |
5 -     let t = *r;  // Try to move the value pointed to by `r`
5 +     let t = r;  // Try to move the value pointed to by `r`
  |
help: consider cloning the value if the performance cost is acceptable
  |
5 -     let t = *r;  // Try to move the value pointed to by `r`
5 +     let t = r.clone();  // Try to move the value pointed to by `r`
  |

Let’s walk through the process:

r is a mutable reference to s, and the *r operation tries to move the value (String does not implement Copy, so s would lose its data)
Since s still exists, Rust expects to be able to drop its memory normally when s goes out of scope
But s has already been moved away, so Rust no longer knows how to drop it correctly, which triggers a compilation error

The correct approach:

fn main() {
    let mut s = String::from("Hello");
    let r = &mut s;

    let t = std::mem::replace(r, String::new()); // Replace the original value with an empty string
    println!("{}", t);  // "Hello"
    println!("{}", s);  // ""
}

1.10.3. Interior Mutability

Some types provide interior mutability, which allows them to modify values through shared references.

These types usually rely on extra mechanisms — such as atomic CPU instructions — or on invariants to provide safe mutability without relying on the semantics of exclusive references.

Interior mutability falls into two categories:

Obtain a mutable reference through a shared reference: Mutex, RefCell
These types provide a guarantee: if a value is exposed through a mutable reference, then only one mutable reference will exist at the same time, and no shared references will exist alongside it. This capability relies on UnsafeCell, the only correct way to modify a value through a shared reference.
Replace a value through a shared reference: std::sync::atomic, std::cell::Cell
These types do not provide a mutable reference to the internal value, but they do provide methods for in-place operations on the value — for example, replacing or reading it. For instance, you cannot get a direct reference to a usize or i32, but you can read and replace the value.

1.10.4. The `Cell` Type

Cell comes from the standard library and provides interior mutability through invariants.

A Cell cannot be shared across threads, because its internal value is not meant to be modified concurrently, even when mutation happens through a shared reference
It does not provide references to the value inside the Cell (so the value can always be moved)

Methods provided by Cell:

Replace the value as a whole, which is the so-called in-place operation
Return a copy of the value, which is reading

1. `set(value)`: Replace the Value

use std::cell::Cell;

fn main() {
    let x = Cell::new(10);  // Create a `Cell` that stores 10

    x.set(20);  // Replace the internal value

    println!("Updated value: {}", x.get()); // Prints 20
}

set(value) replaces the value inside the Cell with a new value

2. `get()`: Return a Copy of the Value

use std::cell::Cell;

fn main() {
    let x = Cell::new(5);
    let y = x.get(); // Get a copy of the value inside `x`
    println!("Value: {}", y); // Prints 5
}

get() does not return a reference to the internal value; it returns a copy of the value (for types that implement the Copy trait).
It works for i32, bool, and other types that implement the Copy trait.

[Advanced Rust] 1.9. Ownership (Quick Recap) - Core Ideas of Ownership, How to Implement Copy Trait, Value Drop, and Drop Order

SomeB1oody — Sat, 25 Jul 2026 20:33:21 +0000

1.9.1. The Core Idea of Ownership

The core idea of Rust’s memory model is that every value has exactly one owner. In other words, only one place — usually a scope — is responsible for freeing each value.

This behavior is enforced by the borrow checker. If a value is moved — for example by assigning it to a new variable, pushing it into a Vec, placing it on the heap, and so on — then the owner becomes the new location.

The owner is really just a location in memory; the place where the data lives is the value’s owner. A move means the data is transferred from one location to another, and the new location becomes the owner.

However, some types do not follow this rule: if a value’s type implements the Copy trait, then reassignment performs a copy rather than a move. That is, a copy of the value is placed in the new location.

1.9.2. How to Implement the `Copy` Trait

Types that implement Copy must be able to duplicate their values bit by bit.

Types that cannot implement Copy naturally include:

Types that contain non-Copy types
Types that must perform special resource-release work when their values are dropped

Why?
Imagine Box<T> implemented Copy. If you assigned box1 = box2, then both variables would believe they owned a heap allocation that belonged exclusively to them. When they went out of scope, both would try to free that memory, causing a double free.

1.9.3. Dropping Values

When a value is no longer needed, its owner deletes it.

Dropping — or discarding — a value happens when it goes out of scope. Types recursively drop the values they contain. For example, deleting a complex type can require deleting many values.

Rust does not drop the same value more than once because of ownership. If a variable contains references to other values that it does not own, then deleting that variable does not delete the other values.

That may be hard to understand, so let’s look at a simple example:

fn main() {  
    let x1 = 42;  
    let y1 = Box::new(x1);  

    {  
        let z = (x1, y1);  
    }  

    let x2 = x1;  
}

x1 is an i32, and y1 is a Box<i32> that owns a heap allocation containing a copy of x1’s value (because i32 is Copy, Box::new(x1) does not borrow x1)
{} creates a new scope, and z is created inside that smaller scope
z is a tuple whose value is (x1, y1). x1 is an i32 and implements Copy, so x1 copies its value into z; y1 is a Box<i32> and does not implement Copy, so it cannot be copied and instead transfers ownership to z
After leaving the inner scope, x1 is used again. x1 is still valid because it copied its value into z and remains usable itself
y1 becomes invalid after being assigned to z because ownership moved to z

1.9.4. The Order of Dropping Values

Variables, including function parameters, are dropped in reverse order of declaration.
Nested values are dropped in source order. In the example above, when the inner scope ends, z is dropped: it first drops its first element (the copied i32), then its second element (the Box). Because y1 was moved into z, y1 itself is not dropped again afterward.

Note: Rust does not currently allow self-referential values inside a single value.

[Advanced Rust] 1.8. Memory Pt.6 - Scanning Address Space Through the Operating System

SomeB1oody — Fri, 24 Jul 2026 17:51:58 +0000

1.8.1. Scan the Address Space Through the Operating System (Example)

Operating systems provide interfaces that let programs make requests — system calls. On Windows, KERNEL32.DLL provides functions for inspecting and manipulating the memory of running processes.

This example is performed on Windows. Why use Windows as the example?

The function names are easy to understand
No knowledge of the POSIX API is required

1.8.2. Dependencies

This example uses the windows-sys crate, which provides low-level bindings to the Windows API. Add the following dependency to Cargo.toml:

[dependencies]
windows-sys = { version = "0.59.0", features = [
    "Win32_Foundation",
    "Win32_System_Memory",
    "Win32_System_ProcessStatus",
    "Win32_System_Threading",
] }

Here we use windows-sys to call Windows APIs such as GetCurrentProcess, K32GetProcessMemoryInfo, and VirtualQueryEx. Those modules are feature-gated, so the features above must be enabled.

1.8.3. Main Program

Then bring the required items into scope in main.rs:

use std::ffi::c_void;
use std::mem;
use windows_sys::Win32::System::Memory::{VirtualQueryEx, MEMORY_BASIC_INFORMATION};
use windows_sys::Win32::System::ProcessStatus::{PROCESS_MEMORY_COUNTERS, K32GetProcessMemoryInfo};
use windows_sys::Win32::System::Threading::{GetCurrentProcess, GetCurrentProcessId};

/// Windows `PVOID` / `SIZE_T` as used by the Win32 APIs.
/// In `windows-sys` 0.59+, these are expressed as raw Rust types rather than
/// named aliases under `Win32::Foundation`.
type PVOID = *mut c_void;
type SIZE_T = usize;

PVOID: Represents a void* pointer, used to describe an opaque memory address. Here it is a local alias for *mut c_void.
SIZE_T: Corresponds to an unsigned integer type used to represent the size of a memory region. Here it is a local alias for usize (matching the windows-sys 0.59+ signatures).
MEMORY_BASIC_INFORMATION: A built-in system structure used to describe the basic information of a memory region.
PROCESS_MEMORY_COUNTERS: A structure used to record a process’s memory usage.
K32GetProcessMemoryInfo: This function retrieves memory information for the current process.
GetCurrentProcess and GetCurrentProcessId: Retrieve the current process handle and process ID, respectively.

For convenient Debug output, we wrap the PROCESS_MEMORY_COUNTERS returned by the Windows API in a custom ProcessInfo structure:

#[derive(Debug)]
struct ProcessInfo {
    cb: u32,
    page_fault_count: u32,
    peak_working_set_size: usize,
    working_set_size: usize,
    quota_peak_paged_pool_usage: usize,
    quota_paged_pool_usage: usize,
    quota_peak_non_paged_pool_usage: usize,
    quota_non_paged_pool_usage: usize,
    pagefile_usage: usize,
    peak_pagefile_usage: usize,
}

cb (u32):
- Description: The size of the structure in bytes.
- Purpose: Identifies the size of the structure for compatibility.
page_fault_count (u32):
- Description: The total number of page faults since the process started.
- Purpose: A page fault is the handling process triggered when a memory access misses physical memory. It includes soft faults (data obtained from the file cache) and hard faults (data loaded from disk).
peak_working_set_size (usize):
- Description: The peak size of the working set used by the process, meaning the memory currently resident in physical memory.
- Purpose: Used to monitor the process’s peak memory usage.
working_set_size (usize):
- Description: The current size of the process’s working set.
- Purpose: Shows how much physical memory the process is currently using.
quota_peak_paged_pool_usage (usize):
- Description: The peak size of the process’s paged-pool quota usage.
- Purpose: The paged pool is kernel-mode memory that can be paged out to disk.
quota_paged_pool_usage (usize)
- Description: The current size of the process’s paged-pool quota usage.
- Purpose: Used to monitor the amount of pageable kernel memory currently in use.
quota_peak_non_paged_pool_usage (usize):
- Description: The peak size of the process’s non-paged-pool quota usage.
- Purpose: The non-paged pool is kernel-mode memory that remains permanently resident in physical memory.
quota_non_paged_pool_usage (usize):
- Description: The current size of the process’s non-paged-pool quota usage.
- Purpose: Used to monitor the amount of non-pageable kernel memory currently in use.
pagefile_usage (usize):
- Description: The current amount of space used by the process in the page file.
- Purpose: Indicates how much of the process’s data has been paged to disk.
peak_pagefile_usage (usize)
- Description: The peak amount of page-file space used by the process.
- Purpose: Used to monitor the process’s page-file high-water mark.

MEMORY_BASIC_INFORMATION from windows-sys does not implement Debug, so we also wrap its fields for printing:

#[derive(Debug)]
struct MemoryBasicInfo {
    base_address: *mut c_void,
    allocation_base: *mut c_void,
    allocation_protect: u32,
    region_size: usize,
    state: u32,
    protect: u32,
    type_: u32,
}

Get the current process handle and process ID (these must go inside an unsafe block):

let this_proc = GetCurrentProcess();
let this_pid = GetCurrentProcessId();

Retrieve process memory information:

let mut mem_counters: PROCESS_MEMORY_COUNTERS = mem::zeroed();
let mem_counters_size = mem::size_of::<PROCESS_MEMORY_COUNTERS>() as u32;
K32GetProcessMemoryInfo(this_proc, &mut mem_counters, mem_counters_size);

let mut mem_counters: PROCESS_MEMORY_COUNTERS = mem::zeroed();
- Use mem::zeroed() to create and initialize a PROCESS_MEMORY_COUNTERS structure so that all of its fields are zero.
- PROCESS_MEMORY_COUNTERS is a predefined Windows structure used to store process memory statistics.
let mem_counters_size = mem::size_of::<PROCESS_MEMORY_COUNTERS>() as u32;
- Use mem::size_of to compute the size of the PROCESS_MEMORY_COUNTERS structure in bytes.
- Convert that size to u32, which is then used as a parameter in the API call below.
K32GetProcessMemoryInfo(this_proc, &mut mem_counters, mem_counters_size);
- Parameter explanation:
  - this_proc: The current process handle, indicating which process’s memory data you want to query.
  - &mut mem_counters: A mutable reference to the PROCESS_MEMORY_COUNTERS structure, used to receive the memory statistics returned by the API.
  - mem_counters_size: The size of the structure, ensuring the API can correctly read and populate the structure data.
- Purpose: Call K32GetProcessMemoryInfo to fill mem_counters with the current process’s memory state, such as the page-fault count, working-set size, and page-file usage.

Wrap the memory information in our custom ProcessInfo:

let proc_info = ProcessInfo {
    cb: mem_counters.cb,
    page_fault_count: mem_counters.PageFaultCount,
    peak_working_set_size: mem_counters.PeakWorkingSetSize,
    working_set_size: mem_counters.WorkingSetSize,
    quota_peak_paged_pool_usage: mem_counters.QuotaPeakPagedPoolUsage,
    quota_paged_pool_usage: mem_counters.QuotaPagedPoolUsage,
    quota_peak_non_paged_pool_usage: mem_counters.QuotaPeakNonPagedPoolUsage,
    quota_non_paged_pool_usage: mem_counters.QuotaNonPagedPoolUsage,
    pagefile_usage: mem_counters.PagefileUsage,
    peak_pagefile_usage: mem_counters.PeakPagefileUsage,
};

Define the starting and ending addresses for the scan:

let min_addr: PVOID = 0 as PVOID;

Set a typical upper bound for a 64-bit user-mode address space:

let max_addr: PVOID = 0x00007FFF_FFFF_FFFF as PVOID;

Print the process information and the address range:

println!("{:p} @ {:p}", this_pid as *const (), this_proc as *const ());
println!("{:?}", proc_info);
println!("min: {:p}, max: {:p}", min_addr, max_addr);

Initialize the parameters required by VirtualQueryEx:

let MEMINFO_SIZE = mem::size_of::<MEMORY_BASIC_INFORMATION>();
let mut base_addr: PVOID = min_addr;
let mut mem_info: MEMORY_BASIC_INFORMATION = mem::zeroed();

let MEMINFO_SIZE = mem::size_of::<MEMORY_BASIC_INFORMATION>();
- Purpose: Compute the size of MEMORY_BASIC_INFORMATION in bytes and store it in MEMINFO_SIZE.
- Reason: The VirtualQueryEx function requires the size of this structure buffer so it can write the query result correctly.
let mut base_addr: PVOID = min_addr;
- Purpose: Initialize the starting address for the virtual-memory scan by setting the first scan address to min_addr.
- base_addr: Represents the starting address of the current query and will be incremented in the loop below to traverse the entire virtual address space.
let mut mem_info: MEMORY_BASIC_INFORMATION = mem::zeroed();
- Purpose: Use mem::zeroed() to create and initialize a MEMORY_BASIC_INFORMATION structure, setting all fields to zero.
- Reason: This structure will store the result of VirtualQueryEx, namely the detailed information of the memory region corresponding to the current query address.

Scan the entire address space by calling VirtualQueryEx in a loop:

loop {
    let rc: SIZE_T = VirtualQueryEx(this_proc, base_addr, &mut mem_info, MEMINFO_SIZE as SIZE_T);

    if rc == 0 {
        break;
    }

    // `MEMORY_BASIC_INFORMATION` from `windows-sys` does not implement `Debug`,
    // so wrap the fields we care about for printing.
    let printable = MemoryBasicInfo {
        base_address: mem_info.BaseAddress,
        allocation_base: mem_info.AllocationBase,
        allocation_protect: mem_info.AllocationProtect,
        region_size: mem_info.RegionSize,
        state: mem_info.State,
        protect: mem_info.Protect,
        type_: mem_info.Type,
    };
    println!("{:#?}", printable);
    // Add the size of the current region to get the next query address
    base_addr = ((base_addr as usize) + mem_info.RegionSize) as PVOID;
    if (base_addr as usize) >= (max_addr as usize) {
        break;
    }
}

1.8.4. Full Code

main.rs:

use std::ffi::c_void;
use std::mem;
use windows_sys::Win32::System::Memory::{VirtualQueryEx, MEMORY_BASIC_INFORMATION};
use windows_sys::Win32::System::ProcessStatus::{PROCESS_MEMORY_COUNTERS, K32GetProcessMemoryInfo};
use windows_sys::Win32::System::Threading::{GetCurrentProcess, GetCurrentProcessId};

/// Windows `PVOID` / `SIZE_T` as used by the Win32 APIs.
/// In `windows-sys` 0.59+, these are expressed as raw Rust types rather than
/// named aliases under `Win32::Foundation`.
type PVOID = *mut c_void;
type SIZE_T = usize;

/// To allow Debug-formatted output, we wrap PROCESS_MEMORY_COUNTERS ourselves.
#[derive(Debug)]
struct ProcessInfo {
    cb: u32,
    page_fault_count: u32,
    peak_working_set_size: usize,
    working_set_size: usize,
    quota_peak_paged_pool_usage: usize,
    quota_paged_pool_usage: usize,
    quota_peak_non_paged_pool_usage: usize,
    quota_non_paged_pool_usage: usize,
    pagefile_usage: usize,
    peak_pagefile_usage: usize,
}

/// `MEMORY_BASIC_INFORMATION` from `windows-sys` does not implement `Debug`.
#[derive(Debug)]
struct MemoryBasicInfo {
    base_address: *mut c_void,
    allocation_base: *mut c_void,
    allocation_protect: u32,
    region_size: usize,
    state: u32,
    protect: u32,
    type_: u32,
}

fn main() {
    unsafe {
        // Get the current process handle and process ID
        let this_proc = GetCurrentProcess();
        let this_pid = GetCurrentProcessId();

        // Get process memory information
        let mut mem_counters: PROCESS_MEMORY_COUNTERS = mem::zeroed();
        let mem_counters_size = mem::size_of::<PROCESS_MEMORY_COUNTERS>() as u32;
        K32GetProcessMemoryInfo(this_proc, &mut mem_counters, mem_counters_size);

        // Wrap the memory information in our custom ProcessInfo
        let proc_info = ProcessInfo {
            cb: mem_counters.cb,
            page_fault_count: mem_counters.PageFaultCount,
            peak_working_set_size: mem_counters.PeakWorkingSetSize,
            working_set_size: mem_counters.WorkingSetSize,
            quota_peak_paged_pool_usage: mem_counters.QuotaPeakPagedPoolUsage,
            quota_paged_pool_usage: mem_counters.QuotaPagedPoolUsage,
            quota_peak_non_paged_pool_usage: mem_counters.QuotaPeakNonPagedPoolUsage,
            quota_non_paged_pool_usage: mem_counters.QuotaNonPagedPoolUsage,
            pagefile_usage: mem_counters.PagefileUsage,
            peak_pagefile_usage: mem_counters.PeakPagefileUsage,
        };

        // Define the start and end addresses of the scan
        let min_addr: PVOID = 0 as PVOID;
        // Set a typical upper bound for a 64-bit user-mode address space
        let max_addr: PVOID = 0x00007FFF_FFFF_FFFF as PVOID;

        // Print
        println!("{:p} @ {:p}", this_pid as *const (), this_proc as *const ());
        println!("{:?}", proc_info);
        println!("min: {:p}, max: {:p}", min_addr, max_addr);

        // Initialize the parameters required by VirtualQueryEx
        let MEMINFO_SIZE = mem::size_of::<MEMORY_BASIC_INFORMATION>();
        let mut base_addr: PVOID = min_addr;
        let mut mem_info: MEMORY_BASIC_INFORMATION = mem::zeroed();

        // Loop over VirtualQueryEx to scan the entire address space
        loop {
            let rc: SIZE_T =
                VirtualQueryEx(this_proc, base_addr, &mut mem_info, MEMINFO_SIZE as SIZE_T);
            if rc == 0 {
                break;
            }

            let printable = MemoryBasicInfo {
                base_address: mem_info.BaseAddress,
                allocation_base: mem_info.AllocationBase,
                allocation_protect: mem_info.AllocationProtect,
                region_size: mem_info.RegionSize,
                state: mem_info.State,
                protect: mem_info.Protect,
                type_: mem_info.Type,
            };
            println!("{:#?}", printable);
            // Add the size of the current region to get the next query address
            base_addr = ((base_addr as usize) + mem_info.RegionSize) as PVOID;
            if (base_addr as usize) >= (max_addr as usize) {
                break;
            }
        }
    }
}

Cargo.toml:

[package]  
name = "RustStudy"  
version = "0.1.0"  
edition = "2021"  

[dependencies]  
windows-sys = { version = "0.59.0", features = [
    "Win32_Foundation",
    "Win32_System_Memory",
    "Win32_System_ProcessStatus",
    "Win32_System_Threading",
] }

1.8.5. Steps for Reading and Writing Process Memory

The logic for reading and writing process memory is fairly simple. Pseudocode:

let pid = some_process_id;
OpenProcess(pid);

loop over the address space {
    call VirtualQueryEx() to reach the next memory block

    use ReadProcessMemory() to access the memory block
    search for a specific pattern

    call WriteProcessMemory() with the value you need
}

let pid = some_process_id;: Get the current process ID
OpenProcess(pid);: Open this process

Linux provides simple APIs: process_vm_readv() and process_vm_writev(), which correspond to ReadProcessMemory() and WriteProcessMemory() on Windows.

[Advanced Rust] 1.7. Memory Part 5 - Heap vs. Stack Memory, Virtual Memory, and Guidelines for Displaying Data in RAM

SomeB1oody — Fri, 24 Jul 2026 17:49:02 +0000

1.7.1. Dynamic Memory Allocation

At any given moment, a running program occupies part of memory. Sometimes the program needs more memory, so it must request it from the operating system; this is called dynamic allocation.

The following diagram shows the steps of dynamic memory allocation:

The program requests memory from the system through the allocator interface. On Unix-like systems this is typically done with malloc()/free(), and on Windows with HeapAlloc()/HeapFree().
The program uses the allocated memory.
If the memory is no longer needed after use, the program releases it back to the operating system.

PS: there is an **allocator* between the program and the system when memory is requested. It is a specialized subroutine hidden behind the scenes of the program, and it performs some optimizations to avoid a large amount of work for the CPU and the operating system.*

1.7.2. Why Is There a Performance Difference Between Stack Memory and Heap Memory?

First of all, it should be made clear that stack memory and heap memory are only concepts; physically, memory does not contain these two separate regions.

The reason stack memory is fast is that:

Local variables of functions (all allocated on the stack) are adjacent to one another in RAM (contiguous layout). A contiguous layout is very cache-friendly.

The reason heap memory is slower is that:

Data allocated on the heap is unlikely to be adjacent to one another.
Accessing data on the heap requires dereferencing a pointer (which involves page-table lookups and then accessing main memory).

A Simple Comparison Between Stack and Heap

Stack	Heap	Notes
Simple	Complex
Safe	Dangerous	Dangerous here means Unsafe Rust
Fast	Slow
Rigid	Flexible

Data structures on the stack cannot change size during their lifetime.
Data structures on the heap are more flexible because the pointer can change.

1.7.3. Virtual Memory

Virtual memory is the memory view seen by a program. All data that a program can access is provided by the operating system within its address space.

Intuitively, a program’s memory is a sequence of bytes, from a starting position 0 to an ending position n. For example, if a program reports that it uses 100 KB of RAM, then n would be around 100000.

Let’s look at an example:

fn main() {
    let mut n_nonzero = 0;

    for i in 0..10000 {
        let ptr = i as *const u8;
        let byte_at_addr = unsafe { *ptr };
        if byte_at_addr != 0 {
            n_nonzero += 1;
        }
    }

    println!("{}", n_nonzero);
}

This example scans the memory of the running program byte by byte, starting at position 0 and ending at 9999.
let ptr = i as *const u8; converts i into an immutable raw pointer of type *const u8 (a u8 occupies one byte) so that the memory address can be checked. Here, we treat each address as one unit. In reality, many values occupy more than one byte and span multiple bytes, but we will ignore that here.
The next line, let byte_at_addr = unsafe { *ptr };, dereferences the pointer (operations on raw pointers must be placed inside an unsafe block) and reads the value into byte_at_addr.
If byte_at_addr is not 0, then n_nonzero increases by 1.
Finally, the value of n_nonzero is printed.

Output:

segmentation fault

segmentation fault means an error that occurs when the CPU or operating system detects that a program is trying to access an illegal (unauthorized) memory address.

A segment refers to a block in virtual memory. Virtual memory is divided into blocks to minimize the space needed for translating between virtual and physical addresses.

So which memory access is illegal? Address 0. When i equals 0, it is effectively a null pointer, and a null pointer cannot be dereferenced. This also partly explains why raw pointer operations must be placed inside an unsafe block.

Let’s start the loop from 1 instead:

fn main() {
    let mut n_nonzero = 1;

    for i in 1..10000 {
        let ptr = i as *const u8;
        let byte_at_addr = unsafe { *ptr };
        if byte_at_addr != 0 {
            n_nonzero += 1;
        }
    }

    println!("{}", n_nonzero);
}

Output:

segmentation fault

The same error.

This example does not work, so let’s switch to another one:

static GLOBAL: i32 = 1000;

fn noop() -> *const i32 {
    let noop_local = 12345;
    &noop_local as *const i32
}

fn main() {
    let local_str = "a";
    let local_int = 123;
    let boxed_str = Box::new("b");
    let boxed_int = Box::new(789);
    let fn_int = noop();

    println!("GLOBAL:    {:p}", &GLOBAL as *const i32);
    println!("local_str: {:p}", local_str.as_ptr());
    println!("local_int: {:p}", &local_int as *const i32);
    println!("boxed_int: {:p}", Box::into_raw(boxed_int));
    println!("boxed_str: {:p}", Box::into_raw(boxed_str));
    println!("fn_int:    {:p}", fn_int);
}

We declare variables such as GLOBAL, local_str, and local_int (static variables also count as variables). Some are stored on the heap, and some are stored on the stack.
We print their memory addresses.
local_str.as_ptr() prints the address of the string data. Prefer that over local_str as *const str with {:p}: a *const str is a wide pointer, and current Rust formats it as Pointer { addr: ..., metadata: ... } rather than a bare hex address.

Output:

GLOBAL:    0x102572ae4
local_str: 0x102572ae0
local_int: 0x16d8c260c
boxed_int: 0x102d89b10
boxed_str: 0x102d89c10
fn_int:    0x16d8c2620

Although our program is very small, the distribution of variables in virtual memory is quite scattered. Still, there is some pattern:

The addresses of GLOBAL and local_str are relatively close.
The addresses of boxed_int and boxed_str are relatively close.
The addresses of local_int and fn_int are relatively close.

The size of virtual memory is roughly 2^48, but physical memory is certainly not that large. In addition, part of the virtual address space is reserved by the system for itself, and those reserved addresses cannot be used.

Through the Example

From these examples, we can learn a few things:

Some memory addresses are illegal. If you access out-of-bounds memory, the program will be terminated.
Memory addresses are not random. Although values of different types appear to be widely distributed in memory, there is actually a pattern.

1.7.4. Translating Virtual Addresses to Physical Addresses

Accessing data in a program requires virtual addresses (a program can only access virtual addresses). Virtual addresses are translated into physical addresses, which involves the program, the operating system, the CPU, and RAM hardware (and sometimes hard disks and other devices as well):

The CPU is responsible for the translation; more specifically, the Memory Management Unit (MMU) inside the CPU performs this work.
The operating system is responsible for storing instructions.
These instructions also exist at predefined addresses in memory.

In the worst case, every memory access triggers two memory lookups: one for the memory being accessed and one for the instructions.

The CPU maintains a cache of recently translated addresses. It has its own fast memory to accelerate memory access. For historical reasons, this memory is called the Translation Lookaside Buffer (TLB).

To improve performance, programmers need to keep data structures compact and avoid deep nesting. This becomes especially important once the TLB capacity is reached (for x86 processors, roughly 100 pages).

Let’s define the terms:

Page: a fixed-size block of bytes in physical memory; on 64-bit systems it is usually 4 KB.
Word: any value whose size is the size of a pointer, i.e. the width of a CPU register. In Rust, usize and isize are word-length types.

Virtual addresses are divided into many blocks called pages, usually 4 KB each. Dividing memory into blocks helps avoid storing a translation mapping for every variable. In addition, pages have a uniform size, which helps avoid memory fragmentation (empty, unusable spaces appearing in available RAM).

Note: the above is only a general guideline; situations such as microcontrollers are different.

1.7.5. Practical Guidelines for Displaying Data in RAM

Keep the hot part of your program within 4 KB so that lookups stay fast and performance remains good. Many programs cannot keep their hot working set within 4 KB, and for such programs the 4 KB target is unrealistic. In that case, the next target should be 4 KB × 100. This means the CPU’s translation cache (TLB) can still support your program.

Avoid deeply nested data structures. If a pointer points to another page, performance will be affected.

When traversing arrays, the access order affects cache utilization (because the CPU reads small blocks of bytes from RAM, called a cache line), which in turn affects program performance. Two-dimensional arrays in C/C++, Rust, Python (NumPy), and similar languages are stored in row-major order. For example:

int matrix[3][3] = {
    {1, 2, 3},
    {4, 5, 6},
    {7, 8, 9}
};

The layout in memory is:

1  2  3  |  4  5  6  |  7  8  9

If you use row-major traversal:

for (int i = 0; i < 3; i++) {
    for (int j = 0; j < 3; j++) {
        process(matrix[i][j]);
    }
}

matrix[i][j] is contiguous in memory, which makes good use of cache lines, reduces RAM access, and improves speed.

If you use column-major traversal:

for (int j = 0; j < 3; j++) {
    for (int i = 0; i < 3; i++) {
        process(matrix[i][j]);
    }
}

Because columns are scattered in memory, accessing matrix[i][j] may cross multiple cache lines. The CPU may frequently load new cache lines from RAM, causing cache misses and hurting performance.

To summarize:

In languages such as C/C++, Rust, and Python (NumPy) that use row-major order by default, try to traverse arrays by row.
In languages such as MATLAB and Fortran that use column-major order, traversing by column is more efficient.

Note:

Virtualization makes things even worse. If you run an application inside a virtual machine, the hypervisor must also translate addresses for the guest operating system. That is why many CPUs include hardware virtualization support — to reduce overhead by reducing the amount of translation work.

If you run containers inside a virtual machine, you add yet another layer of indirection, which also increases latency.

So, if you want bare-metal performance, you have to run the program on bare metal.

DEV Community: SomeB1oody

[Advanced Rust] 2.1. API Design Principles of Unsurprising - Naming Tips, Implementing Common Traits

2.1.1. What Is the Unsurprising Principle?

2.1.2. Naming Tips

2.1.3. Implementing Common Traits

2.1.4. It Is Recommended to Implement the Debug Trait

2.1.5. It Is Recommended to Implement the Send, Unpin, and Sync Traits

[Advanced Rust] 1.17. Orphan Rules, Coherence, and Consistency - Blanket and Covered Implementations

1.17.1. Coherence

1.17.2. Blanket Implementation

1.17.3. Fundamental Types

1.17.4. Covered Implementation

[Advanced Rust] 1.16. Generic Traits - Generic (Type-Parameter) Traits and Associated-Type Traits

1.16.1. Two Ways to Make a Trait Generic

1.16.2. Generic (Type-Parameter) Traits

1.16.3. Associated-Type Traits

You Cannot Implement Deref for Multiple Target Types

You Cannot Use Multiple Items to Implement the Iterator Trait

[Advanced Rust] 1.15. Trait Bounds - Compilation and Dispatch

1.15.1. Static Dispatch

1.15.2. Monomorphization

1.15.3. The Cost of Monomorphization

1.15.4. Dynamic Dispatch

1.15.5. Vtable

1.15.6. Object Safety

1.15.7. self: Sized

1.15.8. Pros and Cons of Dynamic Dispatch

1.15.9. How to Choose Between Static and Dynamic Dispatch

[Advanced Rust] 1.14. Memory Types Pt.2 - Dynamically Sized Types and Wide Pointers, Packed Layouts, Larger Alignment for Speci…

1.14.1. repr(Rust)

1.14.2. Packed Layouts

1.14.3. Giving a Specific Field or Type a Larger Alignment

1.14.4. Memory Representation of Complex Types

1.14.5. Dynamically Sized Types and Wide Pointers

1.14.6. Wide Pointers

[Advanced Rust] 1.13. Memory Types Pt.1 - Alignment, Layout, and the Repr Attribute

1.13.1. The Basic Responsibility of Types

1.13.2. Alignment

1.13.3. Stricter Alignment Rules

1.13.4. Misaligned Access

1.13.5. The Compiler Tries to Use Alignment as Much as Possible

1.13.6. Layout

1.13.7. repr(C)

1.13.8. repr(transparent)

1.13.9. An Example of Using repr

[Advanced Rust] 1.12. Lifetimes (Advanced) Pt.2 - Lifetime Variance, Covariance, Invariance, Contravariance

1.12.1. Lifetime Variance

1.12.2. Three Kinds of Lifetime Variance

1. Covariant

2. Invariant

3. Contravariant

1.12.3. The Role of Lifetime Variance

[Advanced Rust] 1.11. Lifetimes (Advanced) Pt.1 - Review, Borrow Checker, Generic Lifetimes

1.11.1. Review

1.11.2. Borrow Checker

Features of the Borrow Checker

1.11.3. Generic Lifetimes

Two Reminders

[Advanced Rust] 1.10. References and Interior Mutability (Quick Recap) - References, Interior Mutability, Cell Type, and Relate…

1.10.1. References

1. Shared References

2. Mutable References

1.10.2. Owning a Value vs. Owning a Mutable Reference to a Value

1.10.3. Interior Mutability

1.10.4. The Cell Type

1. set(value): Replace the Value

2. get(): Return a Copy of the Value

[Advanced Rust] 1.9. Ownership (Quick Recap) - Core Ideas of Ownership, How to Implement Copy Trait, Value Drop, and Drop Order

1.9.1. The Core Idea of Ownership

1.9.2. How to Implement the Copy Trait

1.9.3. Dropping Values

1.9.4. The Order of Dropping Values

[Advanced Rust] 1.8. Memory Pt.6 - Scanning Address Space Through the Operating System

1.8.1. Scan the Address Space Through the Operating System (Example)

1.8.2. Dependencies

1.8.3. Main Program

- Reason: This structure will store the result of VirtualQueryEx, namely the detailed information of the memory region corresponding to the current query address.

1.8.4. Full Code

1.8.5. Steps for Reading and Writing Process Memory

[Advanced Rust] 1.7. Memory Part 5 - Heap vs. Stack Memory, Virtual Memory, and Guidelines for Displaying Data in RAM

2.1.4. It Is Recommended to Implement the `Debug` Trait

2.1.5. It Is Recommended to Implement the `Send`, `Unpin`, and `Sync` Traits

You Cannot Implement `Deref` for Multiple Target Types

You Cannot Use Multiple `Item`s to Implement the `Iterator` Trait

1.15.7. `self: Sized`

1.14.1. `repr(Rust)`

1.13.7. `repr(C)`

1.13.8. `repr(transparent)`

1.13.9. An Example of Using `repr`

1.10.4. The `Cell` Type

1. `set(value)`: Replace the Value

2. `get()`: Return a Copy of the Value

1.9.2. How to Implement the `Copy` Trait

- Reason: This structure will store the result of `VirtualQueryEx`, namely the detailed information of the memory region corresponding to the current query address.