Rust 的類別系統非常豐富，而結構體（struct）和列舉（enum）是其中兩個最基礎與強大的元件。這些資料結構不僅提供了組織和管理資料的方式，還能與 Rust 的所有權系統和類別特性（trait）無縫整合。在這篇文章中，玄貓將深入剖析這些資料結構的使用方式和最佳實踐。
結構體的多種形式
Rust 中的結構體有幾種不同形式，每種都適用於不同的場景。讓我們從最簡單的開始：
空結構體
struct EmptyStruct {}
struct AnotherEmptyStruct;
空結構體（也稱為單元結構體）在 Rust 中雖然看起來沒什麼用，但實際上在某些場景下非常有價值。它們不佔用任何記憶體空間（0 位元組大小），常用於實作特性（trait）時，當我們只關心行為而不需要儲存資料的情況。注意上面兩種宣告方式都是有效的 - 第一種使用空大括號，第二種直接用分號結尾。
元組結構體
struct TupleStruct(String);
let tuple_struct = TupleStruct("string value".into());
println!("{}", tuple_struct.0);
元組結構體是 Rust 特有的結構體形式，它結合了結構體的命名類別和元組的匿名欄位特性。與普通結構體不同，元組結構體的欄位沒有名稱，只有類別和位置索引。我們使用數字索引（從 0 開始）來存取元素，如 tuple_struct.0 存取第一個元素。元組結構體在需要為元組賦予特定類別名稱的場景中特別有用，比如實作新類別模式（newtype pattern）時。
典型結構體
struct TypicalStruct {
name: String,
value: String,
number: i32,
}
這是最常見的結構體形式，包含多個具名欄位，每個欄位都有名稱和類別。這種結構體非常適合表示具有多個相關屬性的資料。在 Rust 中，結構體欄位的順序對記憶體佈局有影響，但從程式設計角度，我們通常關注的是欄位名稱而非順序。
結構體的可見性規則
結構體及其欄位的可見性控制著誰能存取它們。Rust 提供了精細的可見性控制機制：
pub struct MixedVisibilityStruct {
pub name: String,
pub(crate) value: String,
pub(super) number: i32,
}
在這個例子中，我們看到了不同層級的可見性控制：
pub name- 完全公開，任何匯入此結構體的程式都可以存取pub(crate) value- 只在當前 crate 內可見pub(super) number- 只在父模組可見
預設情況下，結構體欄位具有模組可見性（相當於 pub(self)），即同一模組內的程式碼可以存取和修改這些欄位。這種精細的可見性控制是 Rust 封裝機制的一部分，幫助我們建立更安全、更可維護的程式。
值得注意的是，結構體本身也需要適當的可見性標記才能被外部程式碼使用。如果想讓結構體在 crate 外可見，必須使用 pub struct MyStruct { ... } 宣告。
實作特性（Trait）
在 Rust 中，我們經常需要為結構體實作某些標準特性：
#[derive(Debug, Clone, Default)]
struct DebuggableStruct {
string: String,
number: i32,
}
let debuggable_struct = DebuggableStruct::default();
println!("{:?}", debuggable_struct);
println!("{:?}", debuggable_struct.clone());
#[derive] 屬性允許我們自動為結構體實作某些特性，前提是該結構體的所有欄位都實作了這些特性。以上例子中：
Debug- 提供fmt()方法，用於格式化輸出（如除錯時顯示結構體內容）Clone- 提供clone()方法，用於建立結構體的副本Default- 提供default()方法，回傳該類別的預設（通常是空）例項
使用 #[derive] 可以節省大量手動實作這些特性的工作。執行上面的程式碼，會輸出兩行相同的內容：DebuggableStruct { string: "", number: 0 }，第一行是直接列印預設建構的結構體，第二行是列印它的克隆。
為結構體實作方法
Rust 使用 impl 區塊為結構體新增方法：
impl DebuggableStruct {
fn increment_number(&mut self) {
self.number += 1;
}
}
此方法接收 &mut self 引數，表示它需要一個對結構體例項的可變參照。這允許方法修改結構體的欄位，同時又不取得結構體的所有權。這是 Rust 中最常見的方法實作方式。
另一種方法實作方式是消耗並回傳結構體：
impl DebuggableStruct {
fn incremented_number(mut self) -> Self {
self.number += 1;
self
}
}
這個版本接收 self 引數（而非參照），表示方法取得結構體的所有權。方法內部修改結構體後將其回傳，這樣呼叫者可以繼續使用修改後的結構體。這種模式在鏈式方法呼叫（method chaining）中特別有用，但在大多數情況下，使用 &mut self 的版本更為常見與效率更高，因為它避免了不必要的所有權轉移。
Rust 的列舉類別
Rust 的列舉（enum）遠比其他語言（如 C、C++、Java）中的列舉強大。它不僅可以表示一組命名常數，還可以包含不同類別的資料。
基本列舉
#[derive(Debug)]
enum JapaneseDogBreeds {
AkitaKen,
HokkaidoInu,
KaiKen,
KishuInu,
ShibaInu,
ShikokuKen,
}
println!("{:?}", JapaneseDogBreeds::ShibaInu);
println!("{:?}", JapaneseDogBreeds::ShibaInu as u32);
這是一個基本的列舉，其中每個變體都是單元類別（unit-like type）。第一行列印出 ShibaInu，第二行列印出 4，這是該列舉變體的整數表示。在 Rust 中，列舉變體預設從 0 開始編號，所以 ShibaInu 是第五個變體，對應數值 4。
我們可以將列舉變體轉換為整數，但反向轉換需要自行實作：
impl From<u32> for JapaneseDogBreeds {
fn from(other: u32) -> Self {
match other {
other if JapaneseDogBreeds::AkitaKen as u32 == other => {
JapaneseDogBreeds::AkitaKen
}
other if JapaneseDogBreeds::HokkaidoInu as u32 == other => {
JapaneseDogBreeds::HokkaidoInu
}
other if JapaneseDogBreeds::KaiKen as u32 == other => {
JapaneseDogBreeds::KaiKen
}
other if JapaneseDogBreeds::KishuInu as u32 == other => {
JapaneseDogBreeds::KishuInu
}
other if JapaneseDogBreeds::ShibaInu as u32 == other => {
JapaneseDogBreeds::ShibaInu
}
other if JapaneseDogBreeds::ShikokuKen as u32 == other => {
JapaneseDogBreeds::ShikokuKen
}
_ => panic!("Unknown breed!"),
}
}
}
這段程式碼實作了 From<u32> 特性，允許我們將 u32 轉換為 JapaneseDogBreeds 類別。它使用 match 守衛（match guard）來比對整數值和列舉變體的數值表示，然後回傳對應的列舉變體。如果沒有比對的值，程式會 panic。這種實作方式雖然有些冗長，但提供了類別安全的轉換機制。
指定列舉值
可以為列舉變體指定特定的值：
enum Numbers {
One = 1,
Two = 2,
Three = 3,
}
fn main() {
println!("one={}", Numbers::One as u32);
}
這個例子中，我們明確指定了每個列舉變體對應的值。執行程式會列印 one=1。注意，如果不進行 as u32 轉換，這段程式碼不會編譯，因為 Numbers::One 沒有實作 std::fmt::Display 特性。這種方式實作了類別 C 語言列舉的功能，讓我們可以控制列舉變體的確切數值。
包含資料的列舉
Rust 列舉最強大的特性是能夠在變體中包含各種類別的資料：
enum EnumTypes {
NamedType,
String,
NamedString(String),
StructLike { name: String },
TupleLike(String, i32),
}
這個列舉展示了 Rust 列舉的多種變體形式：
NamedType- 單元變體，不包含任何資料String- 無名類別變體，這裡只是一個名稱，不包含資料NamedString(String)- 包含單一 String 的元組變體StructLike { name: String }- 結構體形式的變體，帶有具名欄位TupleLike(String, i32)- 包含兩個不同類別元素的元組變體
這種彈性使 Rust 的列舉成為表達多種相關但不同類別資料的強大工具。它是 Rust 中實作代數資料類別（algebraic data types）的主要方式，在模式比對中特別有用。
結構體與列舉的實際應用
在實際開發中，結構體和列舉常一起使用，形成強大的資料模型：
enum PaymentMethod {
CreditCard { number: String, expiry: String, cvv: String },
PayPal(String),
BankTransfer { account: String, sort_code: String },
Cash,
}
struct Payment {
amount: f64,
method: PaymentMethod,
timestamp: u64,
}
這個例子展示瞭如何使用列舉和結構體組合來模擬實際場景。PaymentMethod 列舉表示不同的支付方式，每種方式需要不同的資料；Payment 結構體則組合了支付金額、支付方式和時間戳。這種組合能精確反映業務領域中的概念和規則，同時保持類別安全。
為什麼玄貓偏好結構體而非列舉？
在實際專案中，我發現結構體通常比列舉更常用。這主要是因為：
- 結構體更適合表示具有多個屬性的實體
- 結構體可以實作特性，提供更豐富的行為
- 結構體欄位可以單獨修改，而列舉通常需要整體替換
不過，當需要表示"多選一"的情況時，列舉是不可替代的工具。例如，表示 HTTP 請求的結果（成功或各種錯誤），列舉就非常合適：
enum HttpResult {
Success(Response),
NotFound,
ServerError(String),
Timeout(u32),
// 其他可能的結果...
}
這個列舉表示 HTTP 請求可能的結果：成功、未找到、伺服器錯誤或超時。每種結果可能需要不同的附
Rust 類別系統的優雅設計：命名規範、類別名與錯誤處理
在 Rust 的生態系統中，類別系統扮演著核心角色，它不僅提供了程式安全性的保障，還為開發者提供了豐富的表達方式。在處理複雜專案時，理解如何正確命名列舉變體、運用類別名簡化程式碼，以及掌握 Result 的錯誤處理模式，對於寫出優雅與維護性高的程式碼至關重要。
列舉變體的命名規範與最佳實踐
在設計列舉時，保持一致的命名風格非常重要。我發現許多初學 Rust 的開發者常在同一個列舉中混用命名與未命名變體，這會導致程式碼閱讀困難與容易出錯。
例如，以下是一個混合了命名和未命名變體的列舉範例：
enum MixedEnum {
First, // 未命名變體
Second(i32), // 未命名帶值變體
Third { x: i32 }, // 命名變體
}
雖然 Rust 允許這種混合風格，但從工程實踐角度看，最好保持列舉變體的命名風格一致。當我設計複雜系統時，通常根據列舉的用途選擇單一風格：
- 對於簡單標記型列舉，使用未命名變體
- 對於需要攜帶資料的列舉，要麼全部使用元組變體，要麼全部使用命名結構變體
這種一致性讓程式碼更容易理解和維護，也減少了在模式比對時可能出現的錯誤。
類別名：提升程式碼可讀性與維護性的利器
類別名（Type Alias）是 Rust 中一個強大但經常被低估的功能。它允許我們為現有類別提供替代名稱，類別於 C/C++ 中的 typedef 或 C++ 的 using 關鍵字。
類別名有兩個主要用途：
- 為公共類別提供更符合人體工學的名稱，提高程式函式庫用體驗
- 為複雜的類別組合提供簡短的別名，簡化程式碼
簡化內部複雜類別
當我們需要重複使用複雜的類別時，類別名可以大幅提升程式碼的可讀性：
pub(crate) type MyMap = std::collections::HashMap<String, MyStruct>;
有了這個別名，我們可以使用簡單的 MyMap 代替冗長的 std::collections::HashMap<String, MyStruct>，讓程式碼更加簡潔。
為程式函式庫者供便利
在設計公共 API 時，尤其是當使用泛型時，類別名可以幫助使用者容易理解和使用我們的程式函式庫
以下是一個實際例子，來自 dryoc 加密程式函式庫
/// Stack-allocated key type alias for key derivation with [`Kdf`].
pub type Key = StackByteArray<CRYPTO_KDF_KEYBYTES>;
/// Stack-allocated context type alias for key derivation with [`Kdf`].
pub type Context = StackByteArray<CRYPTO_KDF_CONTEXTBYTES>;
這段程式碼定義了兩個類別名 Key 和 Context，它們都是根據 StackByteArray 類別的固定大小陣列。透過這些別名，程式函式庫者需要了解底層實作細節，就能使用語義化的類別名稱。Key 用於金鑰派生功能，而 Context 則用於提供派生上下文象隱藏了複雜性，同時提供了更符合領域語言的 API。
Result：Rust 錯誤處理的核心機制
Rust 的錯誤處理建立在 Result 列舉的基礎上，它是標準函式庫常用的類別之一：
pub enum Result<T, E> {
Ok(T),
Err(E),
}
Result 代表一個可能成功（回傳結果）或失敗（回傳錯誤）的操作。在 Rust 生態系統中，大多數可能失敗的函式都會回傳 Result。
建立自定義錯誤類別
在開發自己的程式函式庫用時，我通常會建立專屬的錯誤類別。雖然可以使用列舉來表示不同種類別錯誤，但對於簡單情況，我傾向於使用包含錯誤訊息的結構體：
#[derive(Debug)]
struct Error {
message: String,
}
這種簡單的錯誤類別足以處理大多數情況，並且容易擴充套件。
使用 ? 運算元簡化錯誤處理
Rust 的 ? 運算元是錯誤處理的利器，它讓我們能夠簡潔地處理錯誤。以下是一個讀取檔案內容的函式範例：
fn read_file(name: &str) -> Result<String, Error> {
use std::fs::File;
use std::io::prelude::*;
let mut file = File::open(name)?;
let mut contents = String::new();
file.read_to_string(&mut contents)?;
Ok(contents)
}
這段程式碼定義了一個函式，用於讀取指定名稱檔案的內容。函式回傳 Result<String, Error>，表示它可能成功回傳檔案內容字串，或者失敗回傳錯誤。
關鍵點在於 ? 運算元的使用：
- 當嘗試開啟檔案
File::open(name)?時，如果操作失敗，?會立即回傳錯誤並結束函式 - 同樣，在
file.read_to_string(&mut contents)?中，如果讀取操作失敗，也會立即回傳錯誤 - 只有當兩個操作都成功時，函式才會執行到
Ok(contents)並回傳檔案內容
這種模式大簡化了錯誤處理流程，使程式碼更加簡潔和可讀。
然而，要使這段程式碼正確編譯，我們還需要實作 From 特性，以便將標準函式庫std::io::Error 轉換為我們自定義的 Error 類別：
impl From<std::io::Error> for Error {
fn from(other: std::io::Error) -> Self {
Self {
message: other.to_string(),
}
}
}
這個實作讓 ? 運算元能夠自動將 std::io::Error 轉換為我們的 Error 類別。
From/Into：類別轉換的標準模式
Rust 標準函式庫的 From 和 Into 特性是類別轉換的根本。這兩個特性提供了標準化的方式來實作類別之間的轉換。
From 特性的定義如下：
pub trait From<T>: Sized {
/// Performs the conversion.
fn from(_: T) -> Self;
}
在實際應用中，通常只需要實作 From 特性，而不需要手動實作 Into。這是因為 Rust 會自動為我們實作對應的 Into 特性。
簡單的字串包裝範例
以下是一個簡單的字串包裝類別，實作了從 &str 到自定義類別的轉換：
struct StringWrapper(String);
impl From<&str> for StringWrapper {
fn from(other: &str) -> Self {
Self(other.into())
}
}
fn main() {
println!("{}", StringWrapper::from("Hello, world!").0);
}
這段程式碼定義了一個包含單一 String 的元組結構體 StringWrapper，並為它實作了 From<&str> 特性。
實作中，我們使用了 other.into() 來將 &str 轉換為 String，這利用了標準函式庫String 實作的 From<&str> 特性。然後，我們將這個 String 包裝到 StringWrapper 中並回傳。
在 main 函式中，我們使用 StringWrapper::from("Hello, world!") 建立一個新的 StringWrapper 例項，並透過 .0 存取其內部的 String 值，然後列印出來。
用於錯誤處理的類別轉換
在錯誤處理中，From 特性特別有用，尤其是當我們使用 ? 運算元時。如果內部函式回傳的錯誤類別與外部函式的 Result 使用的錯誤類別不同，我們需要提供一個 From 實作來進行自動轉換。
看一個實際的例子：
use std::{fs::File, io::Read};
struct Error(String);
fn read_file(name: &str) -> Result<String, Error> {
let mut f = File::open(name)?;
let mut output = String::new();
f.read_to_string(&mut output)?;
Ok(output)
}
這段程式碼在沒有適當的 From 實作時無法編譯，因為 File::open 和 read_to_string 回傳的是 std::io::Error 類別的錯誤。要解決這個問題，我們需要增加以下實作：
impl From<std::io::Error> for Error {
fn from(other: std::io::Error) -> Self {
Self(other.to_string())
}
}
這個實作允許將標準函式庫std::io::Error 轉換為我們自定義的 Error 類別。轉換過程中，我們呼叫 other.to_string() 將錯誤轉換為字串表示，然後包裝在我們的 Error 類別中。
有了這個實作，當使用 ? 運算元時，編譯器會自動呼叫這個轉換函式，將 std::io::Error 轉換為 Error，從而使程式碼成功編譯。
類別系統設計的實用建議
在設計 Rust 程式時，我發現以下關於類別系統的實用建議能夠顯著提高程式碼品質：
保持列舉變體風格一致性：在同一列舉中，選擇一種變體風格並堅持使用，避免混合命名和未命名變體。
積極使用類別名：對於經常使用的複雜類別，建立有意義的類別名，提高程式碼可讀性。
為程式函式庫者供類別名：在設計公共 API 時，為常用的泛型類別組合提供類別名，簡化使用者用體驗。
自定義錯誤類別：為你的程式函式庫用建立專屬的錯誤類別，使錯誤的來源更加清晰。
實作必要的 From 轉換：確保你的錯誤類別實作了必要的
From特性，以便與標準函式庫他程式函式庫誤類別無縫整合。利用 ? 運算元簡化錯誤處理：在可能的情況下使用
?運算元，而不是手動比對Result，這會使程式碼更加簡潔。
透過這些實踐，我們可以充分利用 Rust 類別系統的優勢，建立更加健壯、可維護與易於理解的程式碼。Rust 的類別系統不僅是安全性的保障，更是表達程式設計意圖的強大工具。
Rust 的類別系統提供了豐富的工具來建立清晰、安全與可維護的程式碼。透過列舉的一致性命名、類別名的策略性使用，以及根據 Result 的錯誤處理模式，我們能夠構建出既表達力強又可靠的程式。這些模式不僅提升了程式碼的品質，還能大幅改善開發體驗，讓我們能夠專注於解決實際問題，而不是與類別系統作鬥爭。
進階型別轉換：當轉換可能失敗時
在 Rust 的型別系統中，型別轉換是日常開發中經常面對的課題。在上一篇文章中，我們討論了 From 和 Into 特徵，它們提供了型別之間無失敗轉換的能力。但在實際開發中，型別轉換並非總是能夠成功執行。
TryFrom 與 TryInto：處理可能失敗的轉換
TryFrom 和 TryInto 特徵是 From 和 Into 的進階版本，專為處理那些可能失敗的轉換場景設計。這兩個特徵的核心區別在於它們的轉換方法會回傳 Result 類別，而不是直接回傳轉換後的值。
pub trait TryFrom<T> {
type Error;
fn try_from(value: T) -> Result<Self, Self::Error>;
}
pub trait TryInto<T> {
type Error;
fn try_into(self) -> Result<T, Self::Error>;
}
這段程式碼展示了 TryFrom 和 TryInto 特徵的基本定義。與 From 和 Into 不同，這些特徵包含一個 Error 關聯類別，用於指定轉換失敗時會產生什麼類別的錯誤。轉換方法回傳 Result<T, E>，可以優雅地處理失敗情況，而不必像 From 和 Into 那樣只能選擇程式當機（panic）。
來看一個實際的例子，將字串轉換為整數：
fn main() {
// 使用 TryFrom 處理可能失敗的轉換
let valid_number = "42";
let invalid_number = "四十二";
match i32::try_from(valid_number) {
Ok(num) => println!("轉換成功: {}", num),
Err(e) => println!("轉換失敗: {}", e),
}
// 使用 TryInto 處理可能失敗的轉換
let result: Result<i32, _> = invalid_number.try_into();
if let Err(e) = result {
println!("轉換失敗: {}", e);
}
}
這個例子展示了 TryFrom 和 TryInto 在實際情境中的應用。當我們嘗試將字串轉換為整數時，有些字串（如 “42”）可以成功轉換，而其他字串（如 “四十二”）則會導致轉換失敗。使用 try_from 或 try_into 方法，我們可以透過 Result 優雅地處理這些失敗情況，而不是讓程式直接當機。
型別轉換的最佳實踐
根據我在實際專案中的經驗，以下是使用 From、Into、TryFrom 和 TryInto 特徵進行型別轉換的最佳實踐：
優先實作
From特徵：當需要在型別間進行轉換時，優先實作From特徵。由於標準函式庫為From實作了Into，所以一旦實作了From，就會自動獲得Into的功能。利用現有特徵，避免自定義轉換：儘可能使用 Rust 標準函式庫供的型別轉換特徵，而非編寫自定義的轉換函式。這樣可以確保程式碼符合 Rust 的慣例，並且更容易被其他 Rust 開發者理解。
處理可能失敗的轉換：當轉換可能失敗時，使用
TryFrom和TryInto特徵，而不是回傳Option或在失敗時觸發 panic。提供有意義的錯誤訊息：在實作
TryFrom時，確保提供清晰、有意義的錯誤訊息，以幫助使用者理解轉換失敗的原因。
Rust 與 C 語言的互操作：FFI 相容性處理
在系統程式設計中，有時需要呼叫非 Rust 語言（尤其是 C 語言）編寫的函式庫讓 C 程式呼叫 Rust 函式。這就涉及到外部函式介面（Foreign Function Interface，簡稱 FFI）的使用，以及 Rust 與 C 型別之間的相容性問題。
使 Rust 結構體與 C 結構體相容
Rust 的結構體在預設情況下與 C 結構體不相容。要實作相容，需要注意以下幾點：
使用
#[repr(C)]屬性：這個屬性告訴編譯器以 C 語言相容的方式排列結構體成員。使用
libccrate 中的 C 型別：libccrate 提供了 Rust 型別和 C 型別之間的對映。即使某些型別看起來等價（如i32和 C 中的int），它們在某些平台上可能有不同的大小或對齊要求。
自動化 FFI 繫結生成
為了簡化 FFI 繫結的生成過程，Rust 團隊提供了 rust-bindgen 工具，可以從 C 語言標頭檔自動生成 Rust 繫結。在大多數情況下，使用 rust-bindgen 是處理 FFI 的最佳方式。
但對於簡單的情況，手動建立 FFI 繫結也是可行的。以下是一個步驟：
- 複製 C 結構體定義
- 將 C 型別轉換為 Rust 型別
- 實作函式介面
實作 zlib 的檔案結構體範例
讓我們以 zlib 的 gzFile_s 結構體為例，展示如何在 Rust 中實作 C 結構體的對映：
// C 語言中的 gzFile_s 結構體定義
// struct gzFile_s {
// unsigned have;
// unsigned char *next;
// z_off64_t pos;
// };
// Rust 中對應的結構體
#[repr(C)]
struct GzFileState {
have: c_uint,
next: *mut c_uchar,
pos: i64,
}
type GzFile = *mut GzFileState;
#[link(name = "z")]
extern "C" {
fn gzopen(path: *const c_char, mode: *const c_char) -> GzFile;
fn gzread(file: GzFile, buf: *mut c_uchar, len: c_uint) -> c_int;
fn gzclose(file: GzFile) -> c_int;
fn gzeof(file: GzFile) -> c_int;
}
這段程式碼展示瞭如何在 Rust 中對映 C 語言的 gzFile_s 結構體。使用 #[repr(C)] 屬性確保 Rust 結構體的記憶體佈局與 C 語言相同。type GzFile = *mut GzFileState; 建立了一個類別名，使程式碼易讀。extern "C" 區塊宣告瞭我們將呼叫的 C 函式，#[link(name = "z")] 指示編譯器連結 zlib 函式庫
接下來，讓我們實作一個函式來讀取 gzip 壓縮檔案：
fn read_gz_file(name: &str) -> String {
let mut buffer = [0u8; 0x1000];
let mut contents = String::new();
unsafe {
let c_name = CString::new(name).expect("CString 建立失敗");
let c_mode = CString::new("r").expect("CString 建立失敗");
let file = gzopen(c_name.as_ptr(), c_mode.as_ptr());
if file.is_null() {
panic!(
"無法讀取檔案: {}",
std::io::Error::last_os_error()
);
}
while gzeof(file) == 0 {
let bytes_read = gzread(
file,
buffer.as_mut_ptr(),
(buffer.len() - 1) as c_uint,
);
let s = std::str::from_utf8(&buffer[..(bytes_read as usize)])
.unwrap();
contents.push_str(s);
}
gzclose(file);
}
contents
}
這個函式展示瞭如何使用 FFI 呼叫 zlib 函式庫取 gzip 壓縮檔案。整個過程封裝在 unsafe 區塊中，因為 FFI 呼叫本質上是不安全的（Rust 無法保證 C 函式的安全性）。
函式首先將 Rust 字串轉換為 C 字串（以 null 結尾的 ASCII 字串），然後呼叫 gzopen 開啟檔案。接著，它在一個迴圈中呼叫 gzread 讀取檔案內容，直到 gzeof 表示達到檔案末尾。最後，呼叫 gzclose 關閉檔案並回傳讀取的內容。
深入 Rust 的記憶體管理：堆積積與堆積積
在理解 Rust 的資料結構時，掌握其記憶體管理機制至關重要。雖然 Rust 提供了高階抽象，使得在許多情況下不必深入考慮記憶體管理細節，但瞭解底層機制仍然對編寫高效與無錯誤的程式碼常有價值。
堆積積與堆積積：記憶體管理的兩種方式
Rust 的記憶體管理機制在底層與 C 或 C++ 類別，主要涉及兩種記憶體區域：堆積積（Stack）和堆積積（Heap）。
堆積積記憶體（Stack）
堆積積是一種後進先出（LIFO）的記憶體結構，主要用於儲存函式呼叫過程中的區域性變數和回傳地址。堆積積記憶體有以下特點：
- 分配和釋放速度快：堆積積的分配只需要移動堆積積指標，非常高效。
- 大小固定：在編譯時就需要知道變數的大小。
- 生命週期明確：變數的生命週期與其所在的程式區塊一致，結束區塊時自動釋放。
- 連續記憶體：堆積積上的資料在記憶體中是連續存放的。
堆積積記憶體（Heap）
堆積積是一種動態分配的記憶體區域，用於儲存大小在執行時才確定或需要動態調整大小的資料。堆積積記憶體有以下特點：
- 動態大小：可以在執行時動態分配和調整大小。
- 分配和釋放較慢：相比堆積積的記憶體管理更為複雜。
- 生命週期靈活：資料的生命週期可以超出其建立時的程式區塊。
- 記憶體分散：堆積積上的資料在記憶體中可能是分散的，需要透過指標存取。
在 Rust 中，像 String 和 Vec 這樣的類別會在堆積積上分配記憶體，而基本類別如 i32 和 bool 則通常存放在堆積積上。
記憶體管理的實際應用
讓我們透過一個例子來理解 Rust 中堆積積和堆積積記憶體的使用：
fn main() {
// 堆積積分配 - 大小固定與在編譯時已知
let x = 42; // i32 值直接存放在堆積積上
// 堆積積分配 - 大小可變與在執行時才確定
let s = String::from("Hello, world!"); // 字串的內容存放在堆積積上
// 函式結束時，x 和 s 都會被釋放
// x 直接從堆積積上彈出
// s 的堆積積部分被彈出，同時它的堆積積部分被 drop 方法釋放
}
在這個例子中，整數 x 的
Rust 記憶體架構：深入理解堆積積與堆積積
在我多年開發經驗中，記憶體管理一直是程式語言設計中的核心挑戰。Rust 以其獨特的所有權系統徹底改變了這個領域。今天，讓我們探討 Rust 如何處理記憶體，以及為何這些機制使它成為現代系統程式設計的理想選擇。
堆積積與堆積積：Rust 的記憶體設定基礎
Rust 程式中的資料可以存放在兩個主要位置：堆積積(stack)或堆積積(heap)。這兩種記憶體區域有著根本的差異，影響著程式的效能和行為。
堆積積記憶體的運作方式
在 Rust 中，任何時候需要在堆積積上設定記憶體，都需要使用特定的堆積積設定資料結構，如 Vec、Box 或 String。以下是一些例子：
// 在堆積積上設定記憶體的例子
let heap_integer = Box::new(1); // 使用 Box 在堆積積上存放整數
let heap_integer_vec = vec![0; 100]; // 建立包含100個0的向量
let heap_string = String::from("heap string"); // 建立堆積積字串
Box::new(1)將整數 1 包裝在Box中，強制將這個值設定在堆積積上，而非預設的堆積積。這在需要將大型資料結構傳遞但不想複製整個資料時非常有用。vec![0; 100]建立了一個包含 100 個 0 的向量，整個向量的內容都存放在堆積積上。向量本身的控制結構（長度、容量等）則在堆積積上。String::from("heap string")建立一個String類別，它是根據Vec<u8>實作的，因此字串內容儲存在堆積積上，而非堆積積上的&str。
堆積積記憶體的特性與優勢
堆積積是執行緒本地的記憶體空間，與函式範圍繫結。它使用「後進先出」(LIFO) 的順序進行設定：
// 在堆積積上設定記憶體的例子
let stack_integer = 69420; // 整數直接存放在堆積積
let stack_allocated_string = "stack string"; // 字串字面值存放在靜態記憶體，但參照在堆積積
- 堆積積設定的資料大小必須在編譯時就已知，這是堆積積能夠高效運作的關鍵原因之一。
- 整數變數
stack_integer直接存放在堆積積上，不需額外的記憶體設定操作。 - 字串字面值
"stack string"本身存放在程式的靜態記憶體區域，但指向它的參照（即變數stack_allocated_string）存放在堆積積上。 - 堆積積記憶體由編譯器生成的程式碼自動管理，開發者不需手動處理堆積積記憶體的設定與釋放。
