Rust on kenji.blog

شرح "الملكية" و"الاستعارة" في Rust مقارنة بمؤشرات C++

Sat, 12 Sep 2026 04:00:00 +0900

في برمجة الأنظمة الحديثة، يمثل تحقيق التوازن بين الأداء وأمان الذاكرة تحديًا مستمرًا. لفترة طويلة، سيطرت C++ على هذا المجال كملك متوج، ولكن في السنوات الأخيرة، بدأت لغة Rust في تهديد هذه المكانة. تتمثل الميزة الأبرز في Rust في مفهومي “الملكية (Ownership)” و"الاستعارة (Borrowing)"، اللذين يضمنان أمان الذاكرة في وقت الترجمة دون الحاجة إلى جامع قمامة (Garbage Collection).

في هذه المقالة، سنقارن بالتفصيل بين مؤشرات C++ (المؤشرات الخام، std::unique_ptr، std::shared_ptr) ونموذج الملكية في Rust. سنشرح بشكل شامل كيف يمنع مترجم Rust (مدقق الاستعارة أو Borrow Checker) أخطاء مثل الاستخدام بعد التحرير (Use-After-Free) وسباق البيانات (Data Race)، وذلك مدعومًا بأمثلة برمجية ورسوم توضيحية.

1. أساسيات إدارة الذاكرة: المكدس (Stack) والكومة (Heap)

لفهم أساسيات إدارة الذاكرة، دعونا نراجع أولاً كيف يستخدم البرنامج الذاكرة. تنقسم مساحة الذاكرة بشكل رئيسي إلى “المكدس (Stack)” و"الكومة (Heap)".

المكدس (Stack)

هي المنطقة التي يتم فيها تكديس المتغيرات المحلية وغيرها عند استدعاء الدوال. تتميز بهيكل LIFO (ما يدخل أخيرًا يخرج أولاً)، وتكون عملية تخصيص الذاكرة وتحريرها سريعة جدًا. يتم وضع البيانات التي يمكن تحديد حجمها في وقت الترجمة (Compile time) فقط هنا.

الكومة (Heap)

يتم فيها وضع البيانات التي يُحدد حجمها ديناميكيًا في وقت التشغيل (Runtime)، أو البيانات التي تحتاج إلى البقاء بعد انتهاء نطاق الدالة (Scope). يتم الوصول إليها عبر المؤشرات (Pointers) أو المراجع (References).

في اللغات التي لا تحتوي على جامع قمامة مثل C++ وRust، يمكن صياغة تكلفة إدارة ذاكرة الكومة بمعادلة رياضية كالتالي. بافتراض أن إجمالي عدد الكائنات هو $N$، ومتوسط الوقت المستغرق في التخصيص هو $T_{alloc}$، ومتوسط الوقت المستغرق في التحرير هو $T_{dealloc}$، فإن إجمالي تكلفة إدارة الذاكرة $C_{memory}$ يكون:

$$ C_{memory} = \sum_{i=1}^{N} (T_{alloc, i} + T_{dealloc, i}) + O_{sync} $$

حيث يمثل $O_{sync}$ النفقات الإضافية (Overhead) للتحكم الحصري (مثل كائنات المزامنة Mutex والعمليات الذرية Atomic operations) في بيئة متعددة الخيوط (Multithreaded). نظرًا لأن Rust تحدد توقيت تحرير الذاكرة في وقت الترجمة، فإنها تقضي على مشكلة انخفاض الإنتاجية (Stop-The-World) الناتجة عن جامع القمامة في وقت التشغيل، وتنفذ $T_{dealloc}$ في وقت آمن ومؤكد.

graph TD A["ذاكرة البرنامج"] --> B["المكدس (سريع، حجم ثابت)"] A --> C["الكومة (ديناميكي، أبطأ)"] B --> D["المتغيرات المحلية"] B --> E["المؤشرات/المراجع"] C --> F["بيانات مخصصة ديناميكيًا"] E -.->|"يشير إلى"| F

2. مؤشرات C++: مقايضة بين الحرية والخطر

دعونا نلقي نظرة على تطور إدارة الذاكرة في C++.

عصر المؤشرات الخام (Raw Pointers) ومشاكلها

توفر المؤشرات الخام (*)، الموروثة من لغة C، حرية مطلقة، ولكنها في الوقت نفسه تعتبر بيئة خصبة لأخطاء خطيرة مثل:

تسرب الذاكرة (Memory Leak): نسيان استخدام delete للذاكرة المخصصة بواسطة new.
المؤشرات المتدلية (Dangling Pointer): الوصول إلى مؤشر يشير إلى ذاكرة تم تحريرها (بعد delete).
التحرير المزدوج (Double Free): استخدام delete لنفس مساحة الذاكرة مرتين.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// C++: مثال على المشاكل الناجمة عن المؤشرات الخام
void rawPointerExample() {
 int* ptr = new int(10);
 // ... بعض العمليات ...
 delete ptr;

 // الوصول عن طريق الخطأ مرة أخرى (Use-After-Free / Dangling Pointer)
 // لا يستطيع مترجم C++ تحويل هذا إلى خطأ في وقت الترجمة
 std::cout << *ptr << std::endl; // سلوك غير محدد (Undefined Behavior)
}

ظهور RAII والمؤشرات الذكية (بداية من C++11)

منذ C++11، تم توحيد المؤشرات الذكية المبنية على مفهوم RAII (اكتساب الموارد هو التهيئة)، وأصبح الاستخدام المباشر للمؤشرات الخام غير محبذ.

`std::unique_ptr`

مؤشر يمثل ملكية حصرية (فردية). يتم تحرير الذاكرة تلقائيًا بمجرد الخروج من النطاق. لا يمكن نسخه، بل يُسمح فقط بـ “نقل (Move)” الملكية (باستخدام std::move).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// C++: std::unique_ptr
#include <memory>
#include <iostream>

void uniquePtrExample() {
 std::unique_ptr<int> p1 = std::make_unique<int>(42);
 // std::unique_ptr<int> p2 = p1; // خطأ في وقت الترجمة (النسخ غير مسموح)
 std::unique_ptr<int> p3 = std::move(p1); // نقل الملكية

 // نقطة ضعف C++: بعد النقل، يصبح p1 مساويًا لـ nullptr، ولكن الوصول إليه لا يزال قابلاً للترجمة
 // سيؤدي ذلك إلى انهيار (Segmentation fault) في وقت التشغيل
 // std::cout << *p1 << std::endl;
}

`std::shared_ptr`

مؤشر يسمح لمؤشرات متعددة بمشاركة نفس الكائن. يستخدم عداد المراجع (Reference Counting)، وبمجرد وصول العداد إلى 0، يتم تحرير الذاكرة. يتطلب عمليات زيادة ونقصان ذرية (Atomic)، مما يسبب نفقات إضافية طفيفة في الأداء (تعادل $O_{sync}$ المذكور سابقًا).

3. الملكية (Ownership) في Rust: نقلة نوعية

تضع Rust مفهوم std::unique_ptr الخاص بـ C++ كجوهر لمواصفات اللغة، مع تطبيق “نموذج ملكية” أكثر صرامة.

القواعد الثلاث للملكية

يعتمد نظام الملكية في Rust على ثلاث قواعد بسيطة للغاية:

كل قيمة في Rust تمتلك متغيرًا يُسمى “المالك” (Owner).
يمكن أن يكون هناك مالك واحد فقط في أي وقت.
عندما يخرج المالك من النطاق (Scope)، سيتم تدمير القيمة.

في Rust، يتم “نقل” الموارد افتراضيًا. تنتقل الملكية عن طريق عملية التعيين دون الحاجة إلى تحديد std::move صراحة كما في C++.

1
2
3
4
5
6
7
8


// Rust: نقل الملكية (Move)
fn main() {
 let s1 = String::from("hello"); // بيانات مخصصة في الكومة
 let s2 = s1; // تنتقل الملكية من s1 إلى s2 (موف)

 // الفرق الأكبر مع C++: الوصول إلى متغير بعد نقله يؤدي إلى "خطأ في وقت الترجمة"!
 // println!("{}, world!", s1); // خطأ في الترجمة: value borrowed here after move
}

ميزة “جعل الوصول إلى المتغيرات بعد النقل مستحيلاً في وقت الترجمة” هي أحد الأسباب التي تجعل Rust أكثر أمانًا من std::unique_ptr في C++.

sequenceDiagram participant S1 as "المتغير s1" participant Heap as "ذاكرة الكومة ('hello')" participant S2 as "المتغير s2" S1->>Heap: "يخصص ويملك" Note over S1,S2: "let s2 = s1;" S1--xHeap: "يفقد الملكية (مُبطل)" S2->>Heap: "يأخذ الملكية"

4. الاستعارة (Borrowing) والمراجع

إذا كانت الملكية تنتقل باستمرار، فسيتعين إرجاع الملكية في كل مرة يتم فيها تمرير قيمة إلى دالة، وهو أمر غير مريح للغاية. وهنا يأتي دور “الاستعارة (Borrowing)”. وهو يعادل المؤشرات أو المراجع في C++.

هناك نوعان من الاستعارة في Rust:

المرجع غير القابل للتغيير (Immutable Reference): &T (مشابه لـ const T& في C++)
المرجع القابل للتغيير (Mutable Reference): &mut T (مشابه لـ T& في C++)

القانون الصارم لمدقق الاستعارة (Borrow Checker)

يحتوي مترجم Rust على “مدقق الاستعارة” الذي يتحقق من صحة المراجع. يفرض مدقق الاستعارة القواعد الصارمة التالية:

في أي نطاق معين، يمكن أن يوجد واحد فقط مما يلي:

مرجع واحد قابل للتغيير (&mut T)

عدة مراجع غير قابلة للتغيير (&T)

يُعرف هذا بمبدأ “قراء متعددون أو كاتب واحد (MRSW)” (Multiple Readers XOR Single Writer). يمكن التعبير عن ذلك بواسطة المعامل الرياضي (XOR) (الاستبعاد المنطقي). بالنسبة للحالة $S$، يجب أن يفي عدد المراجع غير القابلة للتغيير $N_r$ وعدد المراجع القابلة للتغيير $N_w$ بالشرط التالي:

$$ (N_r \ge 0 \land N_w = 0) \oplus (N_r = 0 \land N_w = 1) $$

من خلال هذه القاعدة، يتم منع سباق البيانات (Data Race) تمامًا في وقت الترجمة. يحدث سباق البيانات عندما: (1) يصل مؤشران أو أكثر إلى نفس البيانات في وقت واحد، (2) يقوم واحد على الأقل بالكتابة، و (3) لا توجد آلية للمزامنة. تمنع Rust سباق البيانات مسبقًا عن طريق تدمير الشرط (2) في وقت الترجمة.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// Rust: خطأ في وقت الترجمة بسبب انتهاك قواعد الاستعارة
fn main() {
 let mut s = String::from("hello");

 let r1 = &s; // استعارة غير قابلة للتغيير (موافق)
 let r2 = &s; // استعارة غير قابلة للتغيير (موافق)
 // let r3 = &mut s; // خطأ! لا يمكن إنشاء استعارة قابلة للتغيير بينما توجد استعارة غير قابلة للتغيير

 println!("{}, {}", r1, r2);
}

5. منع إبطال المكرر (Iterator Invalidation)

كمثال عملي يبرز قوة مدقق الاستعارة بشكل أفضل، دعونا نلقي نظرة على الخلل الكلاسيكي المعروف باسم “إبطال المكرر”.

إبطال المكرر في C++ (انهيار وقت التشغيل)

عند تعديل std::vector في C++ داخل حلقة تكرارية، هناك احتمال أن يتم إعادة تخصيص الذاكرة الأساسية (Reallocation)، مما يحول المرجع إلى مؤشر متدلٍ (Dangling Pointer).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// C++: خطأ إبطال المكرر
#include <iostream>
#include <vector>

int main() {
 std::vector<int> v = {1, 2, 3};

 // الحصول على مرجع لعنصر في المتجه
 int& first = v[0];

 // إضافة عنصر (إذا كانت السعة غير كافية هنا، فسيتم تخصيص مساحة ذاكرة جديدة،
 // وقد يتم التخلص من المساحة القديمة)
 v.push_back(4);

 // قد يشير first بالفعل إلى ذاكرة تم تحريرها! (سلوك غير محدد)
 std::cout << "The first element is: " << first << std::endl;

 return 0;
}

حماية وقت الترجمة بواسطة Rust

دعونا نكتب نفس المنطق تمامًا باستخدام Rust.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// Rust: منع إبطال المكرر في وقت الترجمة
fn main() {
 let mut v = vec![1, 2, 3];

 // الحصول على مرجع غير قابل للتغيير (بدء الاستعارة)
 let first = &v[0];

 // خطأ! طالما أن `first` يستعير `v` بشكل غير قابل للتغيير،
 // لا يمكنك إجراء استعارة قابلة للتغيير المطلوبة لـ `v.push`.
 // v.push(4);

 println!("The first element is: {}", first);
}

وبهذه الطريقة، تمنع Rust على مستوى المترجم “تعديل القيمة (استعارة قابلة للتغيير) أثناء قراءتها (استعارة غير قابلة للتغيير)"، مما يضمن اكتشاف الأخطاء القاتلة مثل الاستخدام بعد التحرير (Use-After-Free) وإبطال المكرر في وقت الترجمة بشكل مؤكد.

graph LR A["المتغير v (المالك)"] --> B["مصفوفة الكومة [1, 2, 3]"] C["المرجع 'first' (&v[0])"] -.->|"استعارة غير قابلة للتغيير"| B A -->|X "استعارة قابلة للتغيير مرفوضة!"| D["v.push(4)"] style C stroke:#00FF00,stroke-width:2px style D stroke:#FF0000,stroke-width:2px

6. الملكية المشتركة في Rust: `Rc` و `Arc`

توفر Rust أيضًا ملكية مشتركة تعادل std::shared_ptr في C++، ولكن هناك تمييز واضح في الأنواع للاستخدام في خيط واحد (Single Thread) أو عبر خيوط متعددة (Multi-thread).

للخيط الواحد: `Rc<T>` (Reference Counted)

Rc<T> هو مؤشر ذكي يعتمد على عد المراجع ولكنه ليس آمنًا للخيوط (Non-thread-safe). نظرًا لأنه يزيد أو ينقص العداد دون استخدام تعليمات ذرية، فهو سريع جدًا داخل خيط واحد. ومع ذلك، إذا حاولت إرساله إلى خيط آخر، فسيحدث خطأ في الترجمة (لأنه لا ينفذ سمة Send).

للخيوط المتعددة: `Arc<T>` (Atomic Reference Counted)

للمشاركة بين الخيوط، يتم استخدام Arc<T> الذي يقوم بعمليات زيادة ونقصان ذرية (Atomic). تتكبد تكلفة تعادل std::shared_ptr في C++.

علاوة على ذلك، في C++، إذا حاولت عدة خيوط الكتابة في نفس الوقت إلى متغير مشترك بواسطة std::shared_ptr، فسيحدث سباق بيانات. لمنع ذلك، يجب استخدام std::mutex بشكل صحيح يدويًا.

من ناحية أخرى في Rust، لا يمكن لـ Arc<T> تغيير البيانات الداخلية بمفرده. إذا كانت التعديلات ضرورية، يجب دمجه مع كائن مزامنة Mutex<T>.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
 // مزيج من المشاركة الآمنة للخيوط والتحكم الحصري
 // مشابه لـ std::shared_ptr<std::mutex> في C++، لكن المتيوتكس (Mutex) هنا يغلف البيانات
 let counter = Arc::new(Mutex::new(0));
 let mut handles = vec![];

 for _ in 0..10 {
 let counter_clone = Arc::clone(&counter);
 let handle = thread::spawn(move || {
 // عن طريق استدعاء lock()، يمكنك الحصول على مرجع قابل للتغيير (&mut i32) داخليًا
 let mut num = counter_clone.lock().unwrap();
 *num += 1;
 }); // يتم تحرير القفل تلقائيا عند الخروج من النطاق بسبب مبدأ RAII
 handles.push(handle);
 }

 for handle in handles {
 handle.join().unwrap();
 }

 println!("Result: {}", *counter.lock().unwrap());
}

والجدير بالذكر أن Mutex<T> في Rust ليس مجرد آلية قفل فحسب، بل “يغلف البيانات التي يجب حمايتها كنوع”. يمنع هذا التصميم بالكامل خطأ “الوصول إلى البيانات ونسيان القفل” على مستوى الترجمة. النظام مبني بحيث لا يمكنك الحصول على حق الوصول (مرجع) للبيانات الداخلية دون الحصول على القفل أولاً (lock()).

الخلاصة: “فحص مسبق” بواسطة المترجم أم “مسؤولية شخصية” للمطور؟

توفر المؤشرات والمؤشرات الذكية في C++ للمطور تحكمًا متقدمًا وأداءً عاليًا، ولكن الاستخدام الصحيح لها يعتمد على انضباط المطور. على الرغم من أن C++ أصبحت أكثر أمانًا بشكل دراماتيكي مع إدخال RAII و std::unique_ptr، إلا أنها لا تستطيع منع “السلوك غير المحدد” تمامًا على مستوى اللغة، مثل الوصول بعد النقل أو إبطال المكرر.

من ناحية أخرى، من خلال تضمين قواعد الملكية (Ownership) والاستعارة (Borrowing) في المترجم، تكتشف Rust هذه الأخطاء في وقت الترجمة بدلاً من وقت التشغيل. إن الضمان القوي المتمثل في “إذا نجحت عملية الترجمة، فإن الذاكرة آمنة” هو السبب الأكبر الذي جعل Rust تكتسب دعمًا سريعًا في برمجة الأنظمة.

على الرغم من أن القتال ضد مدقق الاستعارة في Rust (Fight the borrow checker) يمثل عقبة كبيرة للمبتدئين، إلا أنه في الواقع قيام المترجم بالنيابة عنك بعملية حسابية معقدة تتمثل في “تتبع مدة بقاء المؤشر”، والتي كان مبرمجو C++ يقومون بها عادة في رؤوسهم.

إذا تعلمت Rust بعد فهم حرية ومخاطر مؤشرات C++، فيجب أن تكون قادرًا على فهم أعمق للفلسفة الكامنة وراء نموذج الملكية و"لماذا تم اعتماده بهذا التصميم”.

هذه المقالة هي دراسة مقارنة حول طرق إدارة الذاكرة في C++ و Rust. نأمل أن تكون بمثابة مرجع لاختيار اللغة المناسبة وفقًا لمتطلبات كل مشروع.

مهندس C++ يشارك تجربته في تعلم Rust: المزايا والعيوب

Sat, 12 Sep 2026 03:00:00 +0900

مقدمة: فجر جديد في برمجة النظم

في هندسة البرمجيات الحديثة، يقف كل من C++ و Rust كعملاقين في طليعة برمجة النظم. لسنوات عديدة، تربعت C++ كملك مطلق في مجالات مثل أنظمة التشغيل، والأجهزة المدمجة، ومحركات الألعاب، وأنظمة التداول عالي التردد (HFT)، حيث يتطلب الأمر استخراج أقصى درجات الأداء من العتاد. بصفتي مهندس C++ أول، بدأت مسيرتي من غابة المؤشرات الخام في حقبة C++98، وواصلت كتابة التعليمات البرمجية بالتزامن مع موجة التحديث التي جلبتها C++11 (إدخال المؤشرات الذكية، وتعبيرات لامدا، و auto)، وصولاً إلى التوسع الهائل في المواصفات مع إصدارات C++14/17/20.

ولكن في السنوات الأخيرة، شهدنا صعودًا دراماتيكيًا للغة Rust كحل للمشاكل الهيكلية التي تعاني منها C++ — وتحديدًا “الافتقار إلى أمان الذاكرة” والذي يؤدي إلى ثغرات أمنية (يُقال إن حوالي 70% من ثغرات CVE ناتجة عن أخطاء في الذاكرة) و “المواصفات المعقدة بلا حدود والسلوك غير المحدد (UB)”. إن اعتمادها الرسمي في نواة Linux، ومشاريع الانتقال واسعة النطاق إلى Rust من قبل شركات التكنولوجيا العملاقة مثل Microsoft و Google و AWS، لا يعتبر مجرد صيحة عابرة، بل يمثل تحولًا جذريًا في نموذج برمجة النظم.

في هذا المقال، سأقوم بصفتي مهندس C++ متمرس غاص بعمق في تعلم Rust واستخدمها في مشاريع فعلية، بمقارنة وشرح “المزايا” و “العيوب” من منظور تقني أساسي يتعلق بمواصفات اللغة.

1. التحول النموذجي في إدارة الذاكرة: من RAII إلى الملكية والاستعارة

حدود RAII في C++ والمؤشرات الذكية

أحد أعظم ابتكارات C++ هو RAII (اكتساب المورد هو تهيئة). هذا المفهوم، الذي يتم فيه تخصيص الموارد في المنشئ (Constructor) وتحريرها تلقائيًا في المدمر (Destructor) عند الخروج من النطاق، قد حرر المطورين من الرعب الناتج عن تسرب الذاكرة بسبب استخدام new و delete يدويًا. بدءًا من C++11، تمت إضافة std::unique_ptr و std::shared_ptr إلى المكتبة القياسية، مما جعل مفهوم الملكية (Ownership) قابلًا للتعبير عنه في الشيفرة.

مع ذلك، فإن المؤشرات الذكية ودلالات النقل (Move Semantics) في C++ تعاني من نقطة ضعف قاتلة تتمثل في عدم اكتمال التحقق الثابت (Static Verification) من قبل المترجم (Compiler).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


#include <iostream>
#include <memory>
#include <string>

void consume(std::unique_ptr<std::string> ptr) {
 std::cout << "Consuming: " << *ptr << std::endl;
}

int main() {
 auto my_ptr = std::make_unique<std::string>("Hello, C++");

 // نقل (Move) الملكية إلى الدالة
 consume(std::move(my_ptr));

 // خطر: في C++، الوصول إلى كائن بعد نقله لا يؤدي إلى خطأ في الترجمة
 // std::move هو مجرد تحويل إلى مرجع قيمة يمينية (T&&)، والمترجم لا يمنع استخدامه
 if (my_ptr) {
 std::cout << "Pointer is still valid?" << std::endl;
 } else {
 std::cout << "Pointer is null." << std::endl;
 }

 // std::cout << *my_ptr << std::endl; // سلوك غير محدد بسبب استخدام الذاكرة بعد تحريرها (Use-After-Free)
 return 0;
}

في C++، هناك دائمًا خطر الوصول الخاطئ إلى كائن تم إفراغه (في حالة صالحة ولكن غير محددة) باستخدام std::move. يؤدي هذا إلى انهيار البرنامج أثناء التشغيل، أو في أسوأ الحالات، إلى ثغرة أمنية مباشرة.

الملكية (Ownership) في Rust والدفاع المطلق لمدقق الاستعارة

تدمج Rust مفهوم “الملكية” في التصميم الأساسي للغة، وتُجري تحليلًا ثابتًا صارمًا من خلال ميزة في المترجم تُعرف باسم مدقق الاستعارة (Borrow Checker).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


fn consume(s: String) {
 println!("Consuming: {}", s);
} // هنا يخرج s من النطاق، ويتم تحرير الذاكرة (Drop)

fn main() {
 let my_string = String::from("Hello, Rust");

 // نقل الملكية إلى الدالة. في Rust، السلوك الافتراضي هو دلالات النقل.
 consume(my_string);

 // خطأ في الترجمة! لا يمكن مطلقًا الوصول إلى المتغير بعد نقله
 // println!("Is it still there? {}", my_string);
}

في Rust، بمجرد انتقال ملكية المتغير، يعامله المترجم على أنه في حالة تعادل “غير مهيأ”، ويمنع تمامًا أي وصول لاحق إليه. نتيجة لذلك، فإن الأخطاء مثل “استخدام الذاكرة بعد تحريرها (Use-After-Free)” أو “المؤشر المتدلي (Dangling Pointer)” نظريًا لا يمكنها اجتياز عملية الترجمة.

graph TD A["C++ std::unique_ptr"] --> B["تطبيق std::move"] B --> C["انتقال الملكية"] C --> D["لا يزال بالإمكان الوصول للمؤشر القديم"] D --> E["احتمال حدوث سلوك غير محدد (UB)"] F["Rust Box / String"] --> G["التمرير كقيمة (نقل)"] G --> H["انتقال الملكية"] H --> I["المترجم يمنع استخدام المتغير القديم"] I --> J["ضمان أمان الذاكرة"]

الاستعارة (Borrowing) والتحكم في القابلية للتغيير

الأقوى من ذلك هو قواعد “الاستعارة (Borrowing)” التي تشير إلى الموارد. تفرض Rust القواعد التالية:

في أي وقت، يمكن أن يوجد إما “عدة مراجع غير قابلة للتغيير (&T)” أو “مرجع واحد قابل للتغيير (&mut T)”.
يجب ألا يعيش المرجع فترة أطول من النطاق الخاص بالبيانات الأصلية (قيود دورة الحياة - Lifetime).

في C++، من السهل إنشاء مراجع أو مؤشرات متعددة قابلة للتغيير (Mutable) لنفس الكائن، مما قد يؤدي إلى تدمير غير متوقع للحالة (مثل إبطال المكرر - Iterator Invalidation). تمنع Rust هذا المزيج من “الأسماء المستعارة (Aliasing) + القابلية للتغيير (Mutability)” على مستوى اللغة، مما يمنع الأخطاء قبل حدوثها.

2. تخطيط الذاكرة والنفقات الرياضية للمؤشرات الذكية

في برمجة النظم، الفهم الدقيق لتخطيط الذاكرة أمر لا غنى عنه. دعونا نقارن بين std::shared_ptr في C++ و std::rc::Rc / std::sync::Arc في Rust.

يدير std::shared_ptr في C++ الموارد عن طريق حساب المراجع، لكنه يستخدم افتراضيًا عمليات ذرية آمنة خيطيًا (std::atomic) لزيادة أو تقليل عدد المراجع. يمكن صياغة النفقات العامة على الذاكرة على النحو التالي:

$$ Overhead_{C++} = sizeof(T) + sizeof(ControlBlock) $$

هنا، تتضمن $ControlBlock$ “عداد المراجع القوية (Strong Ref Count)"، و “عداد المراجع الضعيفة (Weak Ref Count)"، و “المحذف المخصص (Custom Deleter)”. تكمن المشكلة في أنه حتى في الحالات التي يتم فيها استخدامه في خيط واحد (Single-thread)، فإن النفقات العامة للتعليمات الذرية (مثل قفل خط ذاكرة التخزين المؤقت) تحدث دون قيد أو شرط.

في المقابل، تفصل Rust بصرامة المؤشرات الذكية حسب الغرض:

لخيط واحد: Rc<T> (Reference Counted)
لخيوط متعددة: Arc<T> (Atomic Reference Counted)

$$ Overhead_{Rc} = sizeof(T) + 2 \times sizeof(usize) $$ $$ Overhead_{Arc} = sizeof(T) + 2 \times sizeof(AtomicUsize) $$

في Rust، إذا استخدمت Rc<T> المخصص للخيط الواحد، يمكنك تجنب عقوبة العمليات الذرية بالكامل (تجريد بتكلفة صفرية - Zero-cost abstraction). ومن خلال آلية أمان الخيوط التي سيتم مناقشتها لاحقًا، يتم منع تمرير Rc<T> عن طريق الخطأ إلى خيط آخر تمامًا بواسطة نظام الأنواع.

3. أمان الخيوط: صدمة “التزامن بلا خوف”

لطالما كانت البرمجة متعددة الخيوط في C++ محفوفة دائمًا بخطر سباقات البيانات (Data Races) وحالات الجمود (Deadlocks).

مخاطر الكائنات المتبادلة (Mutex) وفصل البيانات في C++

std::mutex في C++ هو مجرد أداة للتحكم الحصري في “كتلة معينة من التعليمات البرمجية (Critical Section)"، ولا يوجد رابط لغوي بين “البيانات المراد حمايتها” و “الكائن المتبادل (Mutex)”.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


#include <iostream>
#include <thread>
#include <mutex>
#include <vector>

std::vector<int> shared_data;
std::mutex mtx;

void worker() {
 // حتى إذا نسي المطور الحصول على القفل، فسيتم الترجمة بشكل طبيعي
 // std::lock_guard<std::mutex> lock(mtx);
 shared_data.push_back(1); // سباق بيانات قاتل!
}

int main() {
 std::thread t1(worker);
 std::thread t2(worker);
 t1.join();
 t2.join();
 return 0;
}

الكائنات المتبادلة (Mutex) في Rust “تمتلك” البيانات

في Rust، تغلف (تمتلك) Mutex<T> نوع البيانات المحمي T باستخدام الأنواع العامة (Generics). للوصول إلى البيانات، يجب عليك استدعاء lock() للحصول على كائن الحارس (Guard). من المستحيل نحويًا لمس البيانات دون الحصول على القفل.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
 // البيانات مغلفة بالكامل داخل Mutex
 let shared_data = Arc::new(Mutex::new(Vec::new()));
 let mut handles = vec![];

 for _ in 0..2 {
 // استنساخ Arc (حساب المراجع الآمن خيطيًا) لمشاركته بين الخيوط
 let data_clone = Arc::clone(&shared_data);
 let handle = thread::spawn(move || {
 // لا يمكنك الوصول إلى Vec الداخلي إذا لم تحصل على القفل
 let mut data = data_clone.lock().unwrap();
 data.push(1);
 });
 handles.push(handle);
 }

 for handle in handles {
 handle.join().unwrap();
 }
}

علاوة على ذلك، تمتلك Rust سمتين أساسيتين (Traits) تضمنان أمان المعالجة المتزامنة:

Send: الأنواع التي يمكن نقل ملكيتها بأمان بين الخيوط
Sync: الأنواع التي يكون من الآمن الإشارة إليها (استعارتها) من عدة خيوط في نفس الوقت

على سبيل المثال، لا ينفذ Rc<T> غير الآمن خيطيًا السمة Send. لذلك، إذا حاولت تمريره إلى thread::spawn، فسيؤدي ذلك فورًا إلى خطأ في الترجمة. بفضل “التزامن بلا خوف (Fearless Concurrency)” هذا، يتم تحرير المطورين من الخوف من الأخطاء، مما يسمح لهم بدفع عملية الموازاة بقوة أكبر.

وفقًا لقانون أمدال (Amdahl’s Law)، يتم التعبير عن الحد الأقصى للإنتاجية النظرية عند وجود جزء قابل للموازاة $P$ ودرجة التوازي $N$ على النحو التالي:

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

تسمح Rust بإجراء عمليات إعادة الهيكلة (Refactoring) لتعظيم قيمة $P$ بأمان تام بالاعتماد على نظام الأنواع.

graph TD A["أمان الخيوط في C++"] --> B["يعتمد على ذاكرة المطور"] B --> C["الـ Mutex منفصل عن البيانات"] C --> D["خطر كبير لحدوث سباقات بيانات صامتة"] E["أمان الخيوط في Rust"] --> F["السمات Send و Sync"] F --> G["الـ Mutex يمتلك البيانات"] G --> H["منع سباقات البيانات في وقت الترجمة"]

4. معالجة الأخطاء: الاستثناءات مقابل أنواع البيانات الجبرية

المعيار لمعالجة الأخطاء في C++ هو “الاستثناءات (Exceptions)”. ومع ذلك، فإن الاستثناءات تجعل تدفق التحكم غير شفاف، وتسبب عقوبات في الأداء (فك المكدس - Stack Unwinding - وتضخم RTTI). في الأنظمة المدمجة ومحركات الألعاب، غالبًا ما يتم تعطيل الاستثناءات تمامًا (-fno-exceptions) واعتماد تصميم يعيد رموز الخطأ الكلاسيكية. في C++23، تم إدخال std::expected، لكن سيستغرق الأمر وقتًا حتى ينتشر في جميع أنحاء النظام البيئي.

لا يوجد مفهوم للاستثناءات في Rust. يتم إرجاع الأخطاء كـ “قيم” بحتة، ويتم التعبير عنها بواسطة النوع المعداد (نوع بيانات جبري) Result<T, E>.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


use std::fs::File;
use std::io::{self, Read};

// بالنظر إلى نوع القيمة المرجعة فقط، يتضح أنه يمكن أن يحدث خطأ IO
fn read_file_content(path: &str) -> Result<String, io::Error> {
 // يؤدي المشغل ? إلى العودة المبكرة (Early return) فورًا في حالة حدوث خطأ، أو يستخرج المحتوى في حالة النجاح
 let mut file = File::open(path)?;
 let mut content = String::new();
 file.read_to_string(&mut content)?;
 Ok(content)
}

هذا المشغل ? ثوري. فهو يزيل التداخل العميق (هرم جمل if) الذي يحدث عند فحص رموز الخطأ في C++، ويحافظ على تدفق الشيفرة النظيف تمامًا كاستخدام الاستثناءات، مع السماح لك بوصف صريح لاستدعاءات الدوال التي ستنقل الخطأ.

5. تعدد الأشكال (Polymorphism): من الدوال الافتراضية والقوالب إلى السمات

يتم تحقيق تعدد الأشكال في C++ بشكل أساسي من خلال وراثة الفئات (Class Inheritance) والإرسال الديناميكي (Dynamic Dispatch) باستخدام الدوال الافتراضية (virtual)، أو الإرسال الثابت (Static Dispatch) باستخدام القوالب (Templates) (مثل CRTP).

في الإرسال الديناميكي، يتم تضمين مؤشر (vptr) إلى جدول الدوال الافتراضية (vtable) في الكائن، وتحدث نفقات إضافية لحل المؤشر عند استدعاء الدالة.

$$ T_{dispatch} = T_{lookup\_in\_vtable} + T_{dereference} $$

تخلت Rust عن “وراثة الفئات” الكلاسيكية الموجهة للكائنات، واعتمدت بدلاً من ذلك مفهوم “السمات (Traits)” (تشبه Concept في C++20، لكنها تتمتع بوظائف أكثر).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


trait Drawable {
 fn draw(&self);
}

struct Circle { radius: f64 }
impl Drawable for Circle {
 fn draw(&self) { println!("Drawing a Circle of radius {}", self.radius); }
}

// إرسال ثابت (Static dispatch) (أحادي الشكل - بدون نفقات عامة)
fn draw_static<T: Drawable>(item: &T) {
 item.draw();
}

// إرسال ديناميكي (Dynamic dispatch) (كائن السمة - Trait Object)
fn draw_dynamic(item: &dyn Drawable) {
 item.draw();
}

أهم ما يميز الإرسال الديناميكي في Rust (dyn Trait) هو أنه لا يمتلك vptr داخل بنية البيانات، بل يستخدم مؤشرًا سمينًا (Fat Pointer). يحتفظ المؤشر السمين بزوج يتكون من “مؤشر إلى البيانات” و “مؤشر إلى vtable”. هذا يجعل من السهل جدًا تنفيذ (أو توسيع) السمات للأنواع المعرفة في المكتبات الخارجية لاحقًا وإرسالها ديناميكيًا.

6. إدارة الحزم ونظام البناء: معاناة CMake مقابل نِعَم Cargo

تعد غياب مدير حزم قياسي أحد أكبر نقاط الضعف في C++. لطالما استنزفت صياغة CMakeLists.txt الغامضة، وتعقيد حل التبعيات بواسطة find_package، والاختلافات في مسارات المكتبات باختلاف أنظمة التشغيل، قدرًا هائلاً من وقت مهندسي C++.

تأتي Rust مزودة بـ Cargo بشكل قياسي، وهو أحد أفضل مديري الحزم وأنظمة البناء في العالم.

graph TD A["بيئة البناء في C++"] --> B["CMakeLists.txt"] B --> C["تكامل vcpkg / Conan"] C --> D["إنشاء Makefiles / Ninja"] D --> E["المترجم (GCC/Clang/MSVC)"] F["بيئة البناء في Rust"] --> G["Cargo.toml"] G --> H["جلب التبعيات من crates.io"] H --> I["rustc (بناء Cargo)"] I --> J["ثنائي جاهز للتشغيل"]

بمجرد إضافة سطر واحد يحتوي على اسم المكتبة التابعة (Crate) وإصدارها في Cargo.toml، يتم حل التبعيات المتعدية وتنزيلها وبناؤها بشكل آلي بالكامل. وعلاوة على ذلك، يتم دمج جميع سلاسل الأدوات اللازمة للتطوير - مثل الاختبار (cargo test)، وتوليد التوثيق (cargo doc)، والتحليل الثابت (cargo clippy)، ومنسق الشيفرة (cargo fmt) - في هذا الأمر الواحد. هذه الراحة قوية لدرجة أنك بمجرد تجربتها، لن ترغب في العودة إلى بيئة بناء C++.

7. عيوب ومنحنى التعلم عند تعلم Rust

لقد تحدثت حتى الآن عن مزايا Rust، ولكن بالتأكيد توجد “جدران” وعيوب سيواجهها مهندس C++ عند وضع Rust موضع التنفيذ الفعلي.

1. صراع مرير مع مدقق الاستعارة

إذا حاولت تنفيذ هياكل البيانات (مثل القوائم المترابطة ثنائية الاتجاه، وهياكل الرسوم البيانية، والهياكل ذاتية المرجعية، وغيرها) التي كنت تربطها “بشكل أو بآخر بمؤشرات خام” في C++ بنفس الطريقة في Rust، فلن تجتاز الترجمة بسبب قيود الملكية ودورة الحياة. لإرضاء مدقق الاستعارة، يتعين عليك استخدام تغليف معقد مثل Rc<RefCell<T>>، أو إعادة التفكير في التصميم من الأساس ليعتمد على مخصصات الساحة (Arena Allocators) أو الإدارة المستندة إلى المؤشرات (Index-based).

2. طول وقت الترجمة

في حين أن بناء C++ يصبح بطيئًا أيضًا بسبب تداخل القوالب (Templates)، إلا أن وقت الترجمة في Rust (خاصة عند البناء النظيف من الصفر - Clean Build) ليس قصيرًا على الإطلاق. وبسبب تزامن مسارات التحسين القوية لـ LLVM، وتوسيع وحدات الماكرو، وأحادية الشكل للأنواع العامة (Monomorphization)، يصبح وقت البناء عنق زجاجة في المشاريع الكبيرة. خلال مرحلة التطوير، من الضروري استخدام حيل مثل الاعتماد الكبير على cargo check.

3. قابلية التشغيل البيني مع قواعد شيفرة C++ الحالية

في حين أن التكامل مع لغة C (عبر FFI) سلس للغاية، إلا أنه من الصعب جدًا ربط Rust مباشرة بقواعد شيفرة C++ الضخمة الحالية (التي تعتمد بشكل كبير على الفئات، والقوالب، والدوال الافتراضية). في السنوات الأخيرة، تطورت أدوات الجسر مثل cxx و autocxx، ولكن لا تزال هناك عقبات كبيرة أمام تحقيق انتقال سلس ومثالي.

الخلاصة: هل يجب علينا الانتقال إلى Rust؟

ستستمر C++ في لعب دور مهم في تطوير محركات الألعاب والبنى التحتية الضخمة الحالية. كما أن التحديثات التي أدخلت عبر C++20/23 كانت ملحوظة، مما جعل كتابة الشيفرة أكثر أمانًا من ذي قبل.

ولكن، بالنسبة لـ “مشاريع برمجة النظم الجديدة”، أجد الآن أنه من الصعب إيجاد سبب يمنعنا من اختيار Rust. بمجرد اجتياز عملية الترجمة، يتم تحريرك من الخوف من السلوكيات غير المحددة (UB) وتدمير الذاكرة، و"اليقين” الذي تقدمه Rust بقدرتها على أداء المعالجة المتزامنة بأمان وبأداء عالٍ يحسن بشكل كبير من النموذج الذهني للمهندس.

بالنسبة لمهندس C++، لا يقتصر تعلم Rust على مجرد حفظ صياغة جديدة (Syntax)، بل هو تجربة رائعة لاكتساب منظور جديد حول “كيفية إدارة الذاكرة والخيوط بشكل آمن”. أدعوكم جميعًا لتجربة راحة Cargo وصرامة مدقق الاستعارة بأنفسكم.