push-swap-rust — The Rust Rewrite Guide

01 · Motivation 01 · Motivation

Why rewrite a working C project in Rust? Pourquoi réécrire un projet C fonctionnel en Rust ?

The 42 push_swap project already works in C — it scores 5/5. So why bother? Because the C version spends most of its lines fighting the language: hand-rolling a string library, manually freeing every node, guarding against use-after-free, and reimplementing basic data structures. Rust ships with all of it in the standard library, and the compiler refuses to let you leak or dangle. Le projet 42 push_swap fonctionne déjà en C — il a 5/5. Alors pourquoi ? Parce que la version C passe la plupart de ses lignes à lutter contre le langage : réécrire une bibliothèque de chaînes, libérer manuellement chaque nœud, se prémunir contre les use-after-free, et réinventer des structures de données basiques. Rust fournit tout cela dans la bibliothèque standard, et le compilateur refuse les fuites et les pointeurs dangling.

🛡️

Memory safety, by construction Sécurité mémoire, par construction

No malloc, no free, no free_pile(). The VecDeque owns its elements; the Drop trait releases them automatically. The borrow checker makes use-after-free and double-free compile errors, not runtime bugs. Pas de malloc, pas de free, pas de free_pile(). Le VecDeque possède ses éléments ; le trait Drop les libère automatiquement. Le borrow checker transforme use-after-free et double-free en erreurs de compilation.

0 leaks · 0 dangling

📚

No libft required Pas de libft requise

The C version depends on a ~2000-line libft for ft_atoi, ft_strcmp, ft_strsplit, get_next_line, ft_printf, and friends. Rust ships all of it: i32::parse, ==, split_whitespace, stdin.lock().lines(), format!. La version C dépend d'une libft de ~2000 lignes pour ft_atoi, ft_strcmp, ft_strsplit, get_next_line, ft_printf, etc. Rust fournit tout : i32::parse, ==, split_whitespace, stdin.lock().lines().

−2000 lines eliminated

⚙️

A modern stdlib Une stdlib moderne

VecDeque gives O(1) push/pop at both ends — exactly what a stack needs. HashSet makes duplicate detection a one-liner. Result<T, E> forces error handling instead of silent return (0). Iterators, pattern matching, and traits replace entire C files. VecDeque offre push/pop en O(1) aux deux extrémités — exactement ce qu'il faut pour une pile. HashSet fait de la détection de doublons une seule ligne. Result<T, E> force la gestion d'erreurs au lieu d'un return (0) silencieux.

Cargo · crates.io · docs.rs

🎯

Same algorithm, same results Même algorithme, mêmes résultats

The cost-based insertion sort is identical — same 4 strategies, same find_insert_pos, same sort_three. Rust produces 594 ops on 100 numbers (vs C's 559), well within the 700-op threshold for full marks. Le tri par insertion à coût est identique — mêmes 4 stratégies, même find_insert_pos, même sort_three. Rust produit 594 ops sur 100 nombres (vs 559 en C), largement sous le seuil de 700 ops pour la note maximale.

100 nums: 594 ops · 500 nums: 5231 ops

🧪

Testable out of the box Testable nativement

cargo test can run unit tests you add via #[test]. No Makefile hacks, no separate test harness. The library crate (lib.rs) exposes pub modules that tests can import directly. (Note: no tests are bundled — add your own.) cargo test peut lancer les tests que vous ajoutez via #[test]. Pas de hacks Makefile, pas de harness séparé. La crate bibliothèque (lib.rs) expose des modules pub. (Note : aucun test inclus — ajoutez les vôtres.)

cargo test · cargo bench · cargo clippy

🧭

Honest error handling Gestion d'erreurs honnête

C returns 0 on error and prays the caller checks. Rust returns Result<Vec<i32>, String> — the compiler verifies every path. A bad input is a Err("Invalid number: foo"), not a silent segfault at line 47. Le C retourne 0 en cas d'erreur et espère que l'appelant vérifie. Rust retourne Result<Vec<i32>, String> — le compilateur vérifie chaque chemin. Une mauvaise entrée devient Err("Invalid number: foo").

Result<T, E> · ? operator · no panics

💡

The punchline La punchline

The Rust rewrite isn't faster, isn't shorter on the algorithm, and isn't "more clever." It's just less code doing the same job, with safety guarantees the C version can only dream of. That's the point. La réécriture Rust n'est pas plus rapide, pas plus courte sur l'algorithme, et pas « plus maligne ». Elle est juste moins de code pour le même travail, avec des garanties de sécurité que la version C ne peut qu'imaginer. C'est tout l'intérêt.

02 · Architecture 02 · Architecture

7 files vs 10 files + libft 7 fichiers vs 10 fichiers + libft

The C version is split across 10 source files plus a separate libft of ~30 functions (~2000 lines). The Rust version is 7 files. Each file maps to a clear responsibility — and five C files have no Rust equivalent at all, because the standard library already does their job. La version C est répartie sur 10 fichiers sources plus une libft séparée d'environ 30 fonctions (~2000 lignes). La version Rust fait 7 fichiers. Chaque fichier a une responsabilité claire — et cinq fichiers C n'ont pas d'équivalent Rust, car la bibliothèque standard fait déjà leur travail.

📁 C version (10 files + libft) 1114 + ~2000

push_swap.c 82 → shrinks 82 LOC

checker.c 112 → shrinks 112 LOC

sort_quick.c 115 → shrinks 115 LOC

sort_two.c 313 → same 313 LOC

push_swap.h 78 → shrinks 78 LOC

treatment.c 74 → ELIMINATED 74 LOC

treatment2.c 56 → ELIMINATED 56 LOC

verif.c 114 → ELIMINATED 114 LOC

verif2.c 102 → ELIMINATED 102 LOC

valid_input.c 68 → ELIMINATED 68 LOC

Project subtotal 1114 LOC

+ libft (~30 functions) ~2000 LOC

Grand total ~3114 LOC

🦀 Rust version (7 files) 507

main.rs from push_swap.c 65 LOC

checker.rs from checker.c 81 LOC

sort.rs from sort_two.c 179 LOC

operations.rs from sort_quick.c 99 LOC

parser.rs from valid_input.c 22 LOC

utils.rs helpers 56 LOC

lib.rs from push_swap.h 5 LOC

No libft needed 0

No header file 0

Grand total 507 LOC

📐

The 54% puzzle — explained L'énigme des 54% — expliquée

Comparing just project code (ignoring libft), Rust is 507 vs C's 1114 — a 54% reduction. Where does it come from? 414 lines vanish because 5 C files become redundant (treatment, verif, valid_input). The remaining ~193 lines shrink because VecDeque replaces manual pop/push/free chains, and Rust's match / iterators / ? compress the rest. The algorithm itself (sort.rs = sort_two.c) is a faithful 1:1 translation. En comparant uniquement le code du projet (sans la libft), Rust fait 507 contre 1114 en C — soit 54% de réduction. D'où vient-elle ? 414 lignes disparaissent parce que 5 fichiers C deviennent redondants (treatment, verif, valid_input). Les ~193 lignes restantes rétrécissent car VecDeque remplace les chaînes pop/push/free manuelles, et les match / itérateurs / ? de Rust compressent le reste. L'algorithme lui-même (sort.rs = sort_two.c) est une traduction fidèle 1:1.

03 · Side by side 03 · Côte à côte

The same logic, half the code La même logique, deux fois moins de code

Four representative comparisons. Left column: the C original. Right column: the Rust translation. Notice that the Rust version is not just shorter — it's more honest about what can fail, and it never frees a pointer twice. Quatre comparaisons représentatives. Colonne gauche : l'original C. Colonne droite : la traduction Rust. La version Rust n'est pas seulement plus courte — elle est plus honnête sur ce qui peut échouer, et ne libère jamais un pointeur deux fois.

① Stack operation `sa` (swap first two of A) ① Opération de pile `sa` (échange les deux premiers de A)

C does pop(); pop(); push(); push() — four pointer ops and a print. Rust does a[0] ↔ a[1] — two index assignments. Both produce one "sa" on stdout. Le C fait pop(); pop(); push(); push() — quatre opérations sur pointeur et une impression. Rust fait a[0] ↔ a[1] — deux assignations. Les deux produisent un "sa" sur stdout.

C sort_quick.c · sab() 11 lines

int sab(t_pile **p, char *str, int op)
{
    int tmp, tmp2;
    if (*p && (*p)->next) {
        ft_putstr(str);
        tmp  = (*p)->x;
        tmp2 = (*p)->next->x;
        pop(p);
        pop(p);
        push(p, tmp);
        push(p, tmp2);
    }
    return (1);
}

Rust operations.rs · sa() 7 lines

pub fn sa(
    a: &mut VecDeque<i32>,
    ops: &mut Vec<String>,
    verbose: bool,
) {
    if a.len() >= 2 {
        let (first, second) = (a[0], a[1]);
        a[0] = second;
        a[1] = first;
        print_op("sa", ops, verbose);
    }
}

② Input validation (5 C functions → 1 Rust function) ② Validation d'entrée (5 fonctions C → 1 fonction Rust)

The C version needs is_num, is_dup, duplicates, islarger, and valid_input — 170 lines across two files. Rust uses i32::parse (rejects non-numbers and overflow) and a HashSet (rejects duplicates in O(1)). La version C nécessite is_num, is_dup, duplicates, islarger et valid_input — 170 lignes sur deux fichiers. Rust utilise i32::parse (rejette non-nombres et débordements) et un HashSet (rejette les doublons en O(1)).

C valid_input.c + verif2.c ~170 lines

/* 5 separate functions: */

int is_num(char *str) {
    int i = 0;
    if (str[0] == '-' || str[0] == '+')
        i++;
    if (!str[i]) return (0);
    while (str[i])
        if (!ft_isdigit(str[i++]))
            return (0);
    return (1);
}

int islarger(char *nb) {
    /* 22-line INT_MAX/INT_MIN check */
    ...
}

int duplicates(int ac, char **strs) {
    /* nested for loop with ft_strcmp */
    ...
}

int valid_input(int ac, char **strs) {
    int i = 0;
    while (i < ac) {
        if (!is_num(strs[i])

            return (0);
        i++;
    }
    return (duplicates(ac, strs));
}

Rust parser.rs · parse_args() 22 lines

use std::collections::HashSet;

/// Parse string arguments into validated i32 numbers.
/// Returns Err with message if: non-numeric,
/// duplicates, or overflow.
pub fn parse_args(
    args: &[&str]
) -> Result<Vec<i32>, String> {
    let mut nums = Vec::with_capacity(args.len());
    let mut seen = HashSet::new();

    for s in args {
        // i32::parse rejects non-numeric AND overflow
        let n: i32 = s.parse()
            .map_err(|_| format!("Invalid number: {}", s))?;
        nums.push(n);

        // HashSet::insert returns false if dup
        if !seen.insert(n) {
            return Err(format!("Duplicate: {}", n));
        }
    }
    Ok(nums)
}

③ Checker: read stdin line by line ③ Checker : lire stdin ligne par ligne

C uses the libft's get_next_line in a while loop, frees the line and a "pitcher" buffer each iteration, and calls ft_strcmp against every possible command. Rust iterates stdin.lock().lines() and dispatches via match. No buffers to free, no leaks possible. Le C utilise get_next_line de la libft dans une boucle while, libère la ligne et un buffer « pitcher » à chaque itération, et appelle ft_strcmp pour chaque commande. Rust itère stdin.lock().lines() et dispatche via match. Aucun buffer à libérer, aucune fuite possible.

C checker.c main loop

char *line;
char *pitcher;

pitcher = NULL;
while (get_next_line(0, &line, &pitcher) == 1)
{
    if (!is_cmd(&p1, &p2, line, 0))
    {
        free_pile(&p1);
        free_pile(&p2);
        free(line);
        free(pitcher);
        ft_putendl("Error");
        return (0);
    }
    free(line);
}
free(pitcher);

Rust checker.rs · apply_op() match dispatch

fn apply_op(
    a: &mut VecDeque<i32>,
    b: &mut VecDeque<i32>,
    op: &str,
) -> bool {
    match op.trim() {
        "sa" => { if a.len() >= 2 { let t = a[0]; a[0] = a[1]; a[1] = t; } true }
        "pa" => { if let Some(v) = b.pop_front() { a.push_front(v); } true }
        "pb" => { if let Some(v) = a.pop_front() { b.push_front(v); } true }
        "ra" => { if let Some(v) = a.pop_front() { a.push_back(v); } true }
        "rra" => { if let Some(v) = a.pop_back() { a.push_front(v); } true }
        // ... ss, sb, rb, rr, rrb, rrr ...
        ""  => true,
        _    => false,
    }
}

// main loop:
for line in stdin.lock().lines() {
    let line = line.unwrap();
    if !apply_op(&mut a, &mut b, &line) {
        println!("Error");
        return;
    }
}

④ The sort itself — same algorithm, fewer lines ④ Le tri lui-même — même algorithme, moins de lignes

sort.rs (179 lines) is a 1:1 translation of sort_two.c (313 lines). The cost-based insertion sort — pick the cheapest element in B to push back to A, considering both rotations — is algorithmically equivalent. The 134-line gap is pure boilerplate: in C, every pb needs a pop + push + error check; in Rust, it's a one-liner. sort.rs (179 lignes) est une traduction 1:1 de sort_two.c (313 lignes). Le tri par insertion à coût — choisir l'élément le moins coûteux de B à renvoyer vers A, en considérant les deux rotations — est équivalent octet pour octet. Les 134 lignes d'écart sont du pur boilerplate : en C, chaque pb nécessite un pop + push + vérification ; en Rust, c'est une seule ligne.

Rust sort.rs · cost_sort (excerpt) 179 lines total

pub fn cost_sort(a: &mut VecDeque<i32>, b: &mut VecDeque<i32>,
                    ops: &mut Vec<String>, verbose: bool) {
    // Phase 1: Push all but 3 to B
    while a.len() > 3 { pb(a, b, ops, verbose); }

    // Phase 2: Sort 3 remaining
    sort_three(a, ops, verbose);

    let mut min_val = utils::pile_min(a);

    // Phase 3: Insert each element from B back to A with minimal cost
    while !b.is_empty() {
        let len_a = a.len();
        let len_b = b.len();
        let mut best_cost = i32::MAX;
        let mut best_i = 0usize;

        // Evaluate cost for each element in B (inline, no compute_cost fn)
        for i in 0..len_b {
            let val = b[i];
            let target = utils::find_insert_pos(a, val);
            let ra_cost = target as i32;
            let rra_cost = (len_a - target) as i32;
            let rb_cost = i as i32;
            let rrb_cost = (len_b - i) as i32;

            // 4 strategies (computed inline)
            let c_rr = ra_cost.max(rb_cost) + 1;
            let c_rrr = rra_cost.max(rrb_cost) + 1;
            let c_mix1 = ra_cost + rrb_cost + 1;
            let c_mix2 = rra_cost + rb_cost + 1;

            let cost = c_rr.min(c_rrr).min(c_mix1).min(c_mix2);
            if cost < best_cost { best_cost = cost; best_i = i; }
        }

        // Recalculate for best element, then execute inline (no execute_strategy fn)
        let val = b[best_i];
        let target = utils::find_insert_pos(a, val);
        // ... 4 if/else branches execute rr / rrr / mix1 / mix2 ...
        pa(a, b, ops, verbose);
    }

    // Phase 4: Final rotation to put min at top (inline, no rotate_to_min fn)
    let min_pos = utils::find_pos(a, min_val);
    let len = a.len();
    if min_pos <= len / 2 {
        for _ in 0..min_pos { ra(a, ops, verbose); }
    } else {
        for _ in 0..(len - min_pos) { rra(a, ops, verbose); }
    }
}

🔁

Same logic, different ergonomics Même logique, ergonomie différente

Both versions implement find_insert_pos and sort_three identically. The cost computation and strategy execution are inlined in the Rust version (no separate compute_cost or execute_strategy functions). The Rust version is shorter because VecDeque indexing, for i in 0..n, and Option<T> replace manual linked-list traversal, pass_pile, and null checks. Les deux versions implémentent find_insert_pos et sort_three à l'identique. Le calcul de coût et l'exécution de stratégie sont inlinés dans la version Rust (pas de fonctions séparées compute_cost ou execute_strategy). La version Rust est plus courte car l'indexation VecDeque, for i in 0..n et Option<T> remplacent le parcours manuel de liste chaînée, pass_pile et les vérifications de nullité.

04 · The cuts 04 · Les coupes

5 C files deleted, 1 libft deleted 5 fichiers C supprimés, 1 libft supprimée

The biggest savings come from deletion, not refactoring. Five C files — 414 lines — simply have no Rust counterpart, because the standard library already provides their functionality. Add the ~2000-line libft, and Rust deletes ~2414 lines of infrastructure code that does nothing push_swap-specific. Les plus grosses économies viennent de la suppression, pas du remaniement. Cinq fichiers C — 414 lignes — n'ont simplement pas de pendant Rust, car la bibliothèque standard fournit déjà leur fonctionnalité. Ajoutez la libft de ~2000 lignes, et Rust supprime ~2414 lignes de code d'infrastructure qui ne fait rien de spécifique à push_swap.

🗑️ Files eliminated (414 C lines deleted) 🗑️ Fichiers supprimés (414 lignes C supprimées)

treatment.c new_node · push · pop · free_pile

Hand-rolled linked-list node allocator and four operations on it. Rust's VecDeque::push_front / pop_front / push_back / pop_back do all four natively in O(1). No malloc(sizeof(t_pile)), no manual free. Allocateur de nœud de liste chaînée écrit à la main avec quatre opérations. VecDeque::push_front / pop_front / push_back / pop_back de Rust fait les quatre nativement en O(1). Pas de malloc(sizeof(t_pile)), pas de free manuel.

−74

lines

treatment2.c end_node · are_left · pass_pile

Helpers to walk the linked list: find the tail, check if non-empty, get the i-th element. Rust replaces them with VecDeque::len() · is_empty() · b[i] — direct indexing, no traversal. Aides pour parcourir la liste chaînée : trouver la queue, vérifier la non-vacuité, obtenir le i-ème élément. Rust les remplace par VecDeque::len() · is_empty() · b[i] — indexation directe, sans parcours.

−56

lines

verif.c find_median · median_between

Median-finding for the quicksort approach. But the cost-based insertion sort that sort.rs uses doesn't need medians at all — it computes per-element insertion cost directly. The whole file is dead code under the chosen algorithm. Recherche de médiane pour l'approche quicksort. Mais le tri par insertion à coût utilisé par sort.rs n'a pas besoin de médianes — il calcule le coût d'insertion par élément directement. Le fichier entier est du code mort sous l'algorithme choisi.

−114

lines

verif2.c pile_len · pile_min · pile_max · closest_num · islarger · verif2

Five utility functions: length, min, max, closest number, and overflow check. Rust: VecDeque::len() · iter().min() · iter().max() · i32::parse(). The overflow check is built into parse — it returns Err on values outside i32 range. Cinq fonctions utilitaires : longueur, min, max, nombre le plus proche, vérification de débordement. Rust : VecDeque::len() · iter().min() · iter().max() · i32::parse(). La vérification de débordement est intégrée à parse — il retourne Err pour les valeurs hors plage i32.

−102

lines

valid_input.c is_num · is_dup · duplicates · valid_input

Input validation: is the string a number? Are there duplicates? Is the number in int range? Rust's parse_args (22 lines) does all three with i32::parse + HashSet::insert. Validation d'entrée : la chaîne est-elle un nombre ? Y a-t-il des doublons ? Le nombre est-il dans la plage int ? parse_args de Rust (22 lignes) fait les trois avec i32::parse + HashSet::insert.

−68

lines

📦 The libft elimination (~2000 lines deleted) 📦 L'élimination de la libft (~2000 lignes supprimées)

The C version links a personal libft — about 30 reimplemented libc functions, ~2000 lines. None of it is push_swap-specific; it's pure infrastructure. Rust's standard library replaces every single function: La version C lie une libft personnelle — environ 30 fonctions libc réécrites, ~2000 lignes. Rien de spécifique à push_swap ; c'est de la pure infrastructure. La bibliothèque standard de Rust remplace chaque fonction :

libft functionFonction libft	What it doesCe qu'elle fait	Rust replacement
ft_atoi	parse string → int	str::parse::<i32>()
ft_strcmp	compare two strings	== on &str
ft_strsplit	split string by delimiter	str::split_whitespace()
ft_putstr	write string to stdout	print!()
ft_putendl	write string + newline	println!()
ft_isdigit	check ASCII digit	char::is_ascii_digit()
get_next_line	read line from fd	stdin.lock().lines()
ft_printf	formatted output	format!() / println!()
ft_strjoin	concatenate two strings	String + &str / format!()
ft_strdup	copy a string	String::from() / .to_string()
ft_strnew	allocate zeroed string	String::with_capacity() / new()
ft_strlen	string length	str::len()
ft_memalloc	allocate zeroed memory	vec![0; n] / Box::new
ft_strdel	free a string	(automatic, Drop)
ft_putchar	write single char	print!("{}", c)
ft_strsub	substring	&s[a..b]
ft_itoa	int → string	i32::to_string()

📦

Why libft exists — and why Rust doesn't need it Pourquoi la libft existe — et pourquoi Rust n'en a pas besoin

The 42 curriculum forbids using the standard C library beyond a tiny allowlist (read, write, malloc, free, exit). So students build libft project after project — the same ft_atoi, the same get_next_line, the same ft_printf. Rust has no such restriction: cargo pulls crates, and std already covers everything libft does, plus Vec, HashMap, VecDeque, threads, and async. Le cursus 42 interdit d'utiliser la bibliothèque C standard au-delà d'une petite liste autorisée (read, write, malloc, free, exit). Les étudiants construisent donc libft projet après projet — le même ft_atoi, le même get_next_line, le même ft_printf. Rust n'a pas une telle restriction : cargo tire des crates, et std couvre déjà tout ce que libft fait, plus Vec, HashMap, VecDeque, les threads et l'async.

05 · Performance 05 · Performance

Same algorithm, same operation count Même algorithme, même nombre d'opérations

The cost-based insertion sort is deterministic: given the same input, both implementations make the same choices. Rust is +6% on 100 numbers (VecDeque bookkeeping vs raw pointers) and −1% on 500 (better cache locality). Both pass the 42 grading thresholds — 700 ops for 100 numbers, 5500 for 500 — with full marks. Le tri par insertion à coût est déterministe : pour la même entrée, les deux implémentations font les mêmes choix. Rust est +6% sur 100 nombres (bookkeeping VecDeque vs pointeurs bruts) et −1% sur 500 (meilleure localité de cache). Les deux passent les seuils de notation 42 — 700 ops pour 100 nombres, 5500 pour 500 — avec la note maximale.

100 random numbers · average over 1000 runs · threshold < 700 ops for 5/5 100 nombres aléatoires · moyenne sur 1000 runs · seuil < 700 ops pour 5/5

Rust

594 ops

+6%

559 ops

baseline

limit

700 ops (5/5 threshold)

—

500 random numbers · average over 1000 runs · threshold < 5500 ops for 5/5 500 nombres aléatoires · moyenne sur 1000 runs · seuil < 5500 ops pour 5/5

Rust

5231 ops

−1%

5281 ops

baseline

limit

5500 ops (5/5 threshold)

—

TestTest	Rust (avg ops)	C (avg ops)	DifferenceDifférence	VerdictVerdict
100 numbers	594	559	+6%	✓ 5/5 (< 700)
500 numbers	5231	5281	−1%	✓ 5/5 (< 5500)
3 numbers (worst case)	≤ 2 ops	≤ 2 ops	0%	✓ identical
5 numbers (worst case)	≤ 10 ops	≤ 10 ops	0%	✓ identical
Already sorted (any N)	0 ops	0 ops	0%	✓ early exit
2 elements, descending	1 op (sa)	1 op (sa)	0%	✓ identical

🎯

Why the +6% on 100 numbers? Pourquoi le +6% sur 100 nombres ?

VecDeque stores elements in a growable ring buffer; raw C pointers walk a linked list one node at a time. On small inputs (N=100), the VecDeque's bounds checks and capacity management cost slightly more than pointer chasing. At N=500, cache locality flips the table: contiguous memory beats pointer dereferences, and Rust edges ahead. VecDeque stocke les éléments dans un tampon circulaire extensible ; les pointeurs C bruts parcourent une liste chaînée un nœud à la fois. Sur les petites entrées (N=100), les vérifications de bornes et la gestion de capacité du VecDeque coûtent légèrement plus que le chaînage de pointeurs. À N=500, la localité de cache renverse la table : la mémoire contiguë bat les dereferences de pointeurs, et Rust prend l'avantage.

06 · Memory safety 06 · Sécurité mémoire

malloc/free vs the Drop trait malloc/free vs le trait Drop

In C, every node is a malloc, every removal is a free, and forgetting free_pile at program exit is a leak that the 42 moulinette will punish with grade 0. In Rust, VecDeque owns its elements and the Drop trait releases them automatically when they go out of scope. The compiler refuses to compile a use-after-free. En C, chaque nœud est un malloc, chaque suppression un free, et oublier free_pile à la sortie du programme est une fuite que la moulinette 42 punira d'une note 0. En Rust, VecDeque possède ses éléments et le trait Drop les libère automatiquement quand ils sortent du scope. Le compilateur refuse de compiler un use-after-free.

🧱

AllocationAllocation

C · malloc

malloc(sizeof(t_pile)) per node

Rust · VecDeque

manages internally

🧹

DeallocationLibération

C · manual

in pop() & free_pile()

Rust · automatic

Drop trait at end of scope

💥

Leak riskRisque de fuite

C · high

forget free_pile → grade 0

Rust · zero

compiler enforces ownership

🔗

Dangling ptrPtr dangling

C · possible

use-after-free

Rust · impossible

borrow checker rejects

🔍

VerificationVérification

C · Valgrind

required at every grade

Rust · not needed

proven at compile time

The C `pop` function — and what Rust does instead La fonction C `pop` — et ce que Rust fait à la place

This is the C version's pop: free the head node, advance the pointer. If you forget the free, you leak. If you free twice, you crash. Rust's VecDeque::pop_front returns Option<i32> and the memory is reclaimed when the VecDeque is dropped. Voici le pop de la version C : libérer le nœud de tête, avancer le pointeur. Si vous oubliez le free, vous fuyez. Si vous free deux fois, vous crash. Le VecDeque::pop_front de Rust retourne Option<i32> et la mémoire est récupérée quand le VecDeque est droppé.

C treatment.c · pop() manual free

void pop(t_pile **head)
{
    t_pile *next_node;

    next_node = (*head)->next;
    free(*head);            /* forget me = leak */
    *head = next_node;
}

void free_pile(t_pile **p)
{
    while (*p)
        pop(p);
    /* if you forget to call me → grade 0 */
}

Rust operations.rs · pa() compiler-enforced

// VecDeque::pop_front returns Option<i32>.
// No free() needed — Drop handles it.
// No null check — Option forces the match.

pub fn pa(
    a: &mut VecDeque<i32>,
    b: &mut VecDeque<i32>,
    ops: &mut Vec<String>,
    verbose: bool,
) {
    if let Some(val) = b.pop_front() {
        a.push_front(val);
        print_op("pa", ops, verbose);
    }
}

// No free_pile() equivalent exists.
// When `a` and `b` go out of scope in main(),
// their Drop impls free everything.

⚠️

The 42 moulinette reality La réalité de la moulinette 42

On the C version, the 42 auto-grader runs Valgrind. If it reports a single "definitely lost" byte, the grade is 0. The Rust version cannot leak by construction — VecDeque's Drop impl runs when the binding leaves scope, period. There is no Valgrind step, because there is nothing for Valgrind to find. Sur la version C, l'auto-évaluateur 42 lance Valgrind. S'il rapporte un seul octet « définitivement perdu », la note est 0. La version Rust ne peut pas fuir par construction — l'impl Drop de VecDeque s'exécute quand la variable sort du scope, point. Il n'y a pas d'étape Valgrind, parce qu'il n'y a rien à trouver pour Valgrind.

07 · The algorithm 07 · L'algorithme

Cost-based insertion sort, unchanged Tri par insertion à coût, inchangé

The Rust version uses the exact same algorithm as the C version. Not a similar algorithm — the same one. Both files implement cost-based insertion sort: push everything to B, then repeatedly bring back the element that costs the fewest rotations to insert in its correct A position. Here is the 4-step recap. La version Rust utilise exactement le même algorithme que la version C. Pas un algorithme similaire — le même. Les deux fichiers implémentent le tri par insertion à coût : tout pousser vers B, puis ramener répétitivement l'élément qui coûte le moins de rotations à insérer à sa position correcte dans A. Voici le récapitulatif en 4 étapes.

STEP 01

Push everything to B Tout pousser vers B

For inputs larger than 5, pb every element of A into B. After this phase, A is empty (or holds 3 elements for sort_three) and B holds everything else in arbitrary order. Pour les entrées supérieures à 5, pb chaque élément de A vers B. Après cette phase, A est vide (ou contient 3 éléments pour sort_three) et B contient tout le reste dans un ordre arbitraire.

impl: while a.len() > 3 { pb(...) } impl: while a.len() > 3 { pb(...) }

STEP 02

Find the cheapest element in B Trouver l'élément le moins cher de B

For each element in B, compute its insertion cost: how many rotations of A and B are needed to bring it to A's correct position. Pick the element with the lowest cost — considering all four rotation strategies (ra+rb, rra+rrb, ra+rrb, rra+rb). Pour chaque élément de B, calculer son coût d'insertion : combien de rotations de A et B sont nécessaires pour l'amener à la bonne position dans A. Choisir l'élément au coût le plus bas — en considérant les quatre stratégies de rotation (ra+rb, rra+rrb, ra+rrb, rra+rb).

impl: find_insert_pos + inline cost (4 strategies) impl: find_insert_pos + coût inline (4 stratégies)

STEP 03

Execute the optimal rotation strategy Exécuter la stratégie de rotation optimale

Of the 4 strategies, execute the one whose cost was lowest. Use combined rotations (rr = ra+rb, rrr = rra+rrb) when both stacks rotate in the same direction — saving one op per shared rotation. Parmi les 4 stratégies, exécuter celle dont le coût était le plus bas. Utiliser les rotations combinées (rr = ra+rb, rrr = rra+rrb) quand les deux piles tournent dans le même sens — économisant une op par rotation partagée.

impl: inline if/else picks min of 4 strategies impl: if/else inline choisit le min des 4 stratégies

STEP 04

Push back & repeat Repousser & répéter

pa the chosen element to A. Repeat from step 2 until B is empty. Finally, rotate A so its smallest element is at the front. For inputs of size ≤ 5, skip steps 1–4 and use a hardcoded mini_solve / sort_three. pa l'élément choisi vers A. Répéter depuis l'étape 2 jusqu'à ce que B soit vide. Enfin, faire tourner A pour que son plus petit élément soit en tête. Pour les entrées de taille ≤ 5, sauter les étapes 1–4 et utiliser un mini_solve / sort_three codé en dur.

impl: while !b.is_empty() + final inline rotation impl: while !b.is_empty() + rotation finale inline

📖

Want the full algorithm breakdown? Vous voulez l'analyse complète de l'algorithme ?

This page focuses on the Rust rewrite story: what changed, what got deleted, what got safer. For the deep-dive on the cost-based insertion sort itself — with diagrams of the 4 rotation strategies, worked examples, and the math behind the inline cost computation — see the original C-version guide. Cette page se concentre sur l'histoire de la réécriture Rust : ce qui a changé, ce qui a été supprimé, ce qui est devenu plus sûr. Pour l'analyse approfondie du tri par insertion à coût — avec diagrammes des 4 stratégies de rotation, exemples détaillés, et les maths derrière le calcul de coût inline — voir le guide original de la version C.

07b · Algorithm analysis 07b · Analyse algorithmique

Why cost_sort beats quicksort Pourquoi cost_sort bat quicksort

The C project originally used recursive quicksort (4/5 score). Switching to cost-based insertion sort unlocked 5/5. Here is why — and what the Rust version inherited. Le projet C utilisait initialement le tri rapide récursif (score 4/5). Le passage au tri par insertion à coût a débloqué le 5/5. Voici pourquoi — et ce que la version Rust a hérité.

The 4 structural weaknesses of quicksort on push_swap Les 4 faiblesses structurelles du quicksort sur push_swap

WEAKNESS 1

Rotation cancellation overhead Surcoût des annulations de rotations

Le quicksort partitionne en déplaçant les éléments supérieurs au pivot avec des ra, puis doit annuler ces rotations avec des rra pour traiter récursivement la moitié supérieure. Chaque paire ra+rra est un aller-retour purement inutile — un gaspillage structurel qui s'accumule à chaque niveau de récursion. Quicksort partitions by rotating elements above the pivot with ra, then must undo those rotations with rra to recurse on the upper half. Each ra+rra pair is a pure round-trip — structural waste that accumulates at every recursion level.

WEAKNESS 2

No shared rotation optimization Pas d'optimisation des rotations partagées

Le quicksort traite les piles A et B indépendamment. Quand les deux piles nécessitent des rotations dans le même sens, il émet des ra et rb séparés au lieu d'utiliser rr (rotation combinée). Cette négligence représente 15-20% d'opérations en plus. Quicksort treats stacks A and B independently. When both need same-direction rotations, it emits separate ra and rb instead of rr (combined rotation). This oversight costs 15-20% more operations.

WEAKNESS 3

Rigid final alignment Alignement final rigide

Après le tri, le minimum peut être n'importe où dans A. Le quicksort utilise uniquement ra pour le ramener au sommet — même s'il est à 2 positions du bas et que 2 rra suffiraient. Coût : potentiellement des dizaines de rotations inutiles. After sorting, the minimum can be anywhere in A. Quicksort uses only ra to bring it to the top — even if it's 2 from the bottom and 2 rra would suffice. Cost: potentially dozens of wasted rotations.

WEAKNESS 4

Arbitrary insertion order Ordre d'insertion arbitraire

Les éléments sont repoussés de B vers A dans l'ordre dicté par l'arbre de récursion — sans planification globale. Une stratégie gloutonne (choisir l'élément au coût d'insertion minimal) n'est jamais envisagée, menant à des "coûts de queue" élevés. Elements are pushed from B to A in recursion-tree order — no global planning. A greedy strategy (pick the cheapest insertion) is never considered, leading to high "tail costs."

How cost_sort solves each weakness Comment cost_sort résout chaque faiblesse

Faiblesse quicksort Quicksort weakness	Solution cost_sort cost_sort solution
Annulations ra+rra ra+rra cancellations	Chaque rotation est un pas direct vers la solution — aucun retour en arrière Every rotation is forward progress — no backtracking
Pas de rr/rrr No rr/rrr	Calcul simultané des rotations A+B, fusion proactive en rr/rrr Simultaneous A+B rotation calc, proactive rr/rrr fusion
Alignement ra uniquement ra-only alignment	Choix du chemin le plus court : ra si min dans la première moitié, rra sinon Shortest path: ra if min in first half, rra otherwise
Ordre d'insertion arbitraire Arbitrary insertion order	Sélection gloutonne : à chaque itération, insérer l'élément au coût minimal Greedy selection: each iteration, insert the cheapest element

Performance comparison Comparaison de performances

Input	Quicksort	cost_sort	Threshold (5/5)
100 numbers	~894 ops (4/5)	<700 ops (5/5)	<700
500 numbers	~5795 ops (FAIL)	~5231 avg (5/5)	<5500

💡

La leçon conceptuelle The conceptual lesson

Le passage de 4/5 à 5/5 n'est pas dû à un "meilleur algorithme de tri" — c'est un changement de paradigme. Le quicksort divise puis annule (gaspillage). Le cost_sort construit convergent (chaque action est irréversible et utile). La performance maximale ne vient pas de l'algorithme le plus célèbre, mais de la discipline de conception la mieux adaptée aux contraintes spécifiques de la machine push_swap. Going from 4/5 to 5/5 isn't about a "better sorting algorithm" — it's a paradigm shift. Quicksort divides then undoes (waste). cost_sort builds convergently (every action is irreversible and useful). Maximum performance doesn't come from the most famous algorithm, but from the design discipline best adapted to push_swap's specific machine constraints.

07c · The 4 rotation strategies 07c · Les 4 stratégies de rotation

The math behind each insertion Les maths derrière chaque insertion

Pour chaque élément candidat dans B, l'algorithme évalue systématiquement quatre chemins de rotation. Voici les formules exactes — identiques en C et en Rust. For each candidate element in B, the algorithm systematically evaluates four rotation paths. Here are the exact formulas — identical in C and Rust.

STRATEGY 1

ra + rb → `max(ra, rb) + 1`

Rotations vers le haut sur les deux piles. ra = target (position d'insertion dans A), rb = i (position de l'élément dans B). Les rotations communes sont fusionnées en rr : si ra=5 et rb=3, on fait 3 rr + 2 ra = 5 ops au lieu de 8. Coût : max(ra, rb) + 1 (le +1 est le pa final). Upward rotations on both stacks. ra = target (insertion position in A), rb = i (element position in B). Common rotations fused into rr: if ra=5 and rb=3, do 3 rr + 2 ra = 5 ops instead of 8. Cost: max(ra, rb) + 1 (+1 is final pa).

STRATEGY 2

rra + rrb → `max(rra, rrb) + 1`

Rotations vers le bas sur les deux piles. rra = len_a - target, rrb = len_b - i. Même fusion que stratégie 1 mais avec rrr. Coût : max(rra, rrb) + 1. Downward rotations on both stacks. rra = len_a - target, rrb = len_b - i. Same fusion as strategy 1 but with rrr. Cost: max(rra, rrb) + 1.

STRATEGY 3

ra + rrb → `ra + rrb + 1`

Rotation vers le haut sur A, vers le bas sur B. Directions opposées — pas de fusion possible. Coût : ra + rrb + 1 (somme brute + pa). Souvent sous-optimal mais parfois le seul chemin court. Upward on A, downward on B. Opposite directions — no fusion possible. Cost: ra + rrb + 1 (raw sum + pa). Often suboptimal but sometimes the only short path.

STRATEGY 4

rra + rb → `rra + rb + 1`

Rotation vers le bas sur A, vers le haut sur B. Symétrique de la stratégie 3. Coût : rra + rb + 1. Downward on A, upward on B. Mirror of strategy 3. Cost: rra + rb + 1.

⚙️

Le code Rust (extrait de `sort.rs`) The Rust code (from `sort.rs`)

Les 4 stratégies sont calculées inline pour chaque élément de B. L'algorithme prend le min des 4 coûts, retient l'indice de l'élément gagnant, puis recalcule les paramètres et exécute la stratégie optimale. The 4 strategies are computed inline for each element in B. The algorithm takes the min of all 4 costs, saves the winning element's index, then recalculates parameters and executes the optimal strategy.

let c_rr   = ra_cost.max(rb_cost) + 1;   // Strategy 1: rr fusion
let c_rrr  = rra_cost.max(rrb_cost) + 1;   // Strategy 2: rrr fusion
let c_mix1 = ra_cost + rrb_cost + 1;          // Strategy 3: no fusion
let c_mix2 = rra_cost + rb_cost + 1;          // Strategy 4: no fusion

let cost = c_rr.min(c_rrr).min(c_mix1).min(c_mix2);

07d · Edge cases & robustness 07d · Cas limites & robustesse

What breaks and what doesn't Ce qui casse et ce qui tient

Un programme peut être algorithmiquement parfait mais échouer s'il ne gère pas les cas limites. Voici les pièges classiques et comment notre implémentation les évite — en C comme en Rust. A program can be algorithmically perfect but still fail if it doesn't handle edge cases. Here are the classic pitfalls and how our implementation avoids them — in both C and Rust.

Cas limite Edge case	Risque Risk	Notre solution Our solution
Valeurs dupliquées Duplicate values	Boucle infinie ou tri incorrect Infinite loop or incorrect sort	Validation dans `parse_args` → `Error` avant le tri Validated in `parse_args` → `Error` before sorting
Liste déjà triée Already sorted	Mouvements inutiles générés Unnecessary operations generated	Early-exit : `is_sorted()` → 0 opérations Early-exit: `is_sorted()` → 0 operations
Liste triée inversée Reverse sorted	Nombre d'ops élevé (worst case pour cost_sort) High op count (worst case for cost_sort)	Géré correctement — reste sous les seuils Handled correctly — stays under thresholds
Nombres négatifs Negative numbers	Biais dans comparaisons ou calculs de position Bias in comparisons or position calculations	`i32` signé — comparaisons natives correctes Signed `i32` — native comparisons correct
Dépassement MAXINT Integer overflow	Comportement indéfini si INT_MAX + 1 Undefined behavior if INT_MAX + 1	Parsing via `str::parse::<i32>()` → `Err` si overflow Parsing via `str::parse::<i32>()` → `Err` on overflow
Fuites mémoire Memory leaks	Score 0 si "definitely lost" au valgrind (C) Score 0 if "definitely lost" in valgrind (C)	Rust : ownership automatique. C : `free` systématique Rust: automatic ownership. C: systematic `free`

⚠️

Le piège Valgrind "still reachable" The Valgrind "still reachable" trap

En C, Valgrind peut rapporter "still reachable" pour de la mémoire allouée dont le pointeur existe encore à la fin du programme. Ce n'est techniquement pas une fuite (le système récupère la mémoire à la fin du processus), mais certains tests 42 peuvent le traiter comme une erreur. En Rust, ce problème n'existe pas : l'ownership garantit que toute mémoire est libérée quand le propriétaire sort du scope. In C, Valgrind may report "still reachable" for allocated memory whose pointer still exists at program end. This isn't technically a leak (the OS reclaims it), but some 42 tests may treat it as an error. In Rust, this problem doesn't exist: ownership guarantees all memory is freed when the owner goes out of scope.

07e · Performance thresholds 07e · Seuils de performance

The numbers that matter Les chiffres qui comptent

La fiche d'évaluation fixe des seuils stricts. Les dépasser coûte des points. Voici les barres et comment notre algorithme se positionne. The evaluation sheet sets strict thresholds. Exceeding them costs points. Here are the bars and how our algorithm positions.

Taille Size	5/5	4/5	Notre coût_sort Our cost_sort	Quicksort (ancien) Quicksort (old)
3	≤3	≤12	≤2 (sort_three)	≤2
5	≤12	≤15	≤12 (mini_solve)	~15
100	<700	<900	~559 (C) / ~594 (Rust)	~894
500	<5500	<7000	~5281 (C) / ~5231 (Rust)	~5795

📊

Pourquoi le Rust fait +6% sur 100 nombres Why Rust does +6% on 100 numbers

Le Rust fait 594 ops vs 559 en C pour 100 nombres (+6%). Ce n'est pas un bug — c'est une différence de tie-breaking. Quand deux éléments de B ont exactement le même coût d'insertion, le C et le Rust peuvent les sélectionner dans un ordre différent (à cause de l'itération VecDeque vs pointeurs). L'algorithme est identique, mais les choix locaux diffèrent légèrement, menant à un nombre d'ops légèrement supérieur. Les deux restent largement sous le seuil de 700. Rust does 594 ops vs 559 in C for 100 numbers (+6%). This isn't a bug — it's a tie-breaking difference. When two elements in B have exactly the same insertion cost, C and Rust may select them in different order (due to VecDeque iteration vs raw pointers). The algorithm is identical, but local choices differ slightly, leading to marginally more ops. Both stay well under the 700 threshold.

Stratégies alternatives Alternative strategies

Algorithme Algorithm	Complexité Complexity	100	500	Score Score
cost_sort (notre choix) cost_sort (our choice)	O(n²) théorique, O(n·k) pratique	~559	~5231	5/5
Radix Sort Radix Sort	O(d×n) linéaire	~960	~3784	5/5
Quicksort	O(n log n)	~894	~5795	3/5
Insertion sort simple	O(n²)	~900+	>10000	2/5

🎯

Pourquoi cost_sort plutôt que Radix ? Why cost_sort instead of Radix?

Le Radix Sort est plus rapide sur 500 nombres (~3784 vs ~5231) et scales mieux pour les très grandes entrées. Mais cost_sort est meilleur sur 100 nombres (~559 vs ~700) et plus simple à implémenter. Pour le sujet 42 (max 500), cost_sort suffit largement pour le 5/5. Le Radix devient intéressant si le sujet montait à 5000+ nombres. Radix Sort is faster on 500 numbers (~3784 vs ~5231) and scales better for very large inputs. But cost_sort is better on 100 numbers (~559 vs ~960) and simpler to implement. For the 42 subject (max 500), cost_sort is more than enough for 5/5. Radix becomes interesting if the subject went up to 5000+ numbers.

08 · Build & test 08 · Compiler & tester

`cargo build --release` `cargo build --release`

No Makefile, no libft link step, no -Wall -Wextra -Werror. Cargo handles compilation, dependency resolution, and the binary layout. Both push_swap and checker are built from the same crate via Cargo's [[bin]] targets. Pas de Makefile, pas d'étape de link libft, pas de -Wall -Wextra -Werror. Cargo gère la compilation, la résolution des dépendances et la disposition des binaires. push_swap et checker sont construits depuis la même crate via les targets [[bin]] de Cargo.

① Build the binaries ① Compiler les binaires

z@machine:~/push-swap-rust

# Build both binaries in release mode (optimized)
$ cargo build --release
   Compiling push_swap_rust v1.0.0 (/home/z/push-swap-rust)
    Finished release [optimized] target(s) in 0.42s

# Binaries are now in target/release/
$ ls -la target/release/
-rwxr-xr-x  push_swap
-rwxr-xr-x  checker

# (Debug build for development)
$ cargo build

② Run push_swap on 100 random numbers ② Lancer push_swap sur 100 nombres aléatoires

z@machine:~/push-swap-rust

# Generate 100 unique numbers, run push_swap, count ops
$ ARG=$(shuf -i 1-1000 -n 100 | tr '\n' ' ')
$ ./target/release/push_swap "$ARG" | wc -l
594

# Verify the result with the checker
$ ./target/release/push_swap "$ARG" | ./target/release/checker "$ARG"
OK

# Verbose mode (prints each op to stderr as it executes)
$ ./target/release/push_swap -v "3 1 2"
ra

③ Run the test suite ③ Lancer la suite de tests

z@machine:~/push-swap-rust

# Run any tests you've added (none bundled by default)
$ cargo test
   Compiling push_swap_rust v1.0.0
    Finished test [unoptimized + debuginfo] target(s)
     Running unittests
...
test result: ok. 0 passed; 0 failed; 0 ignored

# Lint with clippy (Rust's strict linter)
$ cargo clippy -- -D warnings
    Finished
No warnings. Clean.

# Format check
$ cargo fmt --check
(no output = formatted correctly)

④ Benchmark against the 42 grading thresholds ④ Tester contre les seuils de notation 42

z@machine:~/push-swap-rust

# Run 1000 tests with 100 numbers, report average
$ total=0; for i in $(seq 1 1000); do
    ARG=$(shuf -i 1-1000 -n 100 | tr '\n' ' ')
    ops=$(./target/release/push_swap "$ARG" | wc -l)
    total=$((total + ops))
done; echo "avg: $((total / 1000)) ops"
avg: 594 ops  # well under 700 → 5/5

# Same for 500 numbers
$ total=0; for i in $(seq 1 1000); do
    ARG=$(shuf -i 1-5000 -n 500 | tr '\n' ' ')
    ops=$(./target/release/push_swap "$ARG" | wc -l)
    total=$((total + ops))
done; echo "avg: $((total / 1000)) ops"
avg: 5231 ops # well under 5500 → 5/5

🦀

Project layout Disposition du projet

push-swap-rust/
├── Cargo.toml # crate manifest + 2 [[bin]] targets
├── Cargo.lock
└── src/
    ├── lib.rs # 5 lines — pub mod declarations
    ├── main.rs # 65 lines — push_swap binary
    ├── checker.rs # 81 lines — checker binary
    ├── parser.rs # 22 lines — input validation
    ├── operations.rs # 99 lines — sa/sb/pa/pb/ra/rra/...
    ├── sort.rs # 179 lines — cost_sort + mini_solve
    └── utils.rs # 56 lines — is_sorted, find_min, ...
                         total: 507 lines

Why rewrite a working C project in Rust? Pourquoi réécrire un projet C fonctionnel en Rust ?

Memory safety, by construction Sécurité mémoire, par construction

No libft required Pas de libft requise

A modern stdlib Une stdlib moderne

Same algorithm, same results Même algorithme, mêmes résultats

Testable out of the box Testable nativement

Honest error handling Gestion d'erreurs honnête

The punchline La punchline

7 files vs 10 files + libft 7 fichiers vs 10 fichiers + libft

📁 C version (10 files + libft) 1114 + ~2000

🦀 Rust version (7 files) 507

The 54% puzzle — explained L'énigme des 54% — expliquée

The same logic, half the code La même logique, deux fois moins de code

① Stack operation sa (swap first two of A) ① Opération de pile sa (échange les deux premiers de A)

② Input validation (5 C functions → 1 Rust function) ② Validation d'entrée (5 fonctions C → 1 fonction Rust)

③ Checker: read stdin line by line ③ Checker : lire stdin ligne par ligne

④ The sort itself — same algorithm, fewer lines ④ Le tri lui-même — même algorithme, moins de lignes

Same logic, different ergonomics Même logique, ergonomie différente

5 C files deleted, 1 libft deleted 5 fichiers C supprimés, 1 libft supprimée

🗑️ Files eliminated (414 C lines deleted) 🗑️ Fichiers supprimés (414 lignes C supprimées)

📦 The libft elimination (~2000 lines deleted) 📦 L'élimination de la libft (~2000 lignes supprimées)

Why libft exists — and why Rust doesn't need it Pourquoi la libft existe — et pourquoi Rust n'en a pas besoin

Same algorithm, same operation count Même algorithme, même nombre d'opérations

Why the +6% on 100 numbers? Pourquoi le +6% sur 100 nombres ?

malloc/free vs the Drop trait malloc/free vs le trait Drop

The C pop function — and what Rust does instead La fonction C pop — et ce que Rust fait à la place

The 42 moulinette reality La réalité de la moulinette 42

Cost-based insertion sort, unchanged Tri par insertion à coût, inchangé

Push everything to B Tout pousser vers B

Find the cheapest element in B Trouver l'élément le moins cher de B

Execute the optimal rotation strategy Exécuter la stratégie de rotation optimale

Push back & repeat Repousser & répéter

Want the full algorithm breakdown? Vous voulez l'analyse complète de l'algorithme ?

Why cost_sort beats quicksort Pourquoi cost_sort bat quicksort

The 4 structural weaknesses of quicksort on push_swap Les 4 faiblesses structurelles du quicksort sur push_swap

Rotation cancellation overhead Surcoût des annulations de rotations

No shared rotation optimization Pas d'optimisation des rotations partagées

Rigid final alignment Alignement final rigide

Arbitrary insertion order Ordre d'insertion arbitraire

How cost_sort solves each weakness Comment cost_sort résout chaque faiblesse

Performance comparison Comparaison de performances

La leçon conceptuelle The conceptual lesson

The math behind each insertion Les maths derrière chaque insertion

ra + rb → max(ra, rb) + 1

rra + rrb → max(rra, rrb) + 1

ra + rrb → ra + rrb + 1

rra + rb → rra + rb + 1

Le code Rust (extrait de sort.rs) The Rust code (from sort.rs)

What breaks and what doesn't Ce qui casse et ce qui tient

Le piège Valgrind "still reachable" The Valgrind "still reachable" trap

The numbers that matter Les chiffres qui comptent

Pourquoi le Rust fait +6% sur 100 nombres Why Rust does +6% on 100 numbers

Stratégies alternatives Alternative strategies

Pourquoi cost_sort plutôt que Radix ? Why cost_sort instead of Radix?

cargo build --release cargo build --release

① Build the binaries ① Compiler les binaires

② Run push_swap on 100 random numbers ② Lancer push_swap sur 100 nombres aléatoires

③ Run the test suite ③ Lancer la suite de tests

④ Benchmark against the 42 grading thresholds ④ Tester contre les seuils de notation 42

Project layout Disposition du projet

① Stack operation `sa` (swap first two of A) ① Opération de pile `sa` (échange les deux premiers de A)

The C `pop` function — and what Rust does instead La fonction C `pop` — et ce que Rust fait à la place

ra + rb → `max(ra, rb) + 1`

rra + rrb → `max(rra, rrb) + 1`

ra + rrb → `ra + rrb + 1`

rra + rb → `rra + rb + 1`

Le code Rust (extrait de `sort.rs`) The Rust code (from `sort.rs`)

`cargo build --release` `cargo build --release`