El crate alloc: recuperar Vec, Box y String sin std

no_std te quita el montículo, y con él Vec, Box y String. Pero fíjate en la razón exacta por la que se fueron: no porque necesiten un sistema operativo, sino porque necesitan asignar memoria dinámica, y sin std no hay quien la reparta. Esas son dos exigencias distintas, y Rust las separa con precisión de cirujano. Entre core —que no asigna nada— y std —que asume un SO entero— existe un tercer crate, alloc, que contiene justo los tipos del montículo y pide a cambio una única cosa: que tú digas de dónde sale la memoria. Ni ficheros, ni hilos, ni red: solo un asignador. Provéelo, y recuperas Vec y String en un microcontrolador que jamás ha oído hablar de un sistema operativo.

La capa intermedia

alloc es un crate del sysroot, hermano de core y std, que contiene exactamente los tipos que necesitan un montículo y nada más del sistema. Es más: el propio std toma Box, Vec y String de alloc y los reexporta. std::vec::Vec es alloc::vec::Vec. La pila de capas queda así, y tú eliges en qué piso te plantas:

flowchart LR
CORE[core sin asignador] --> ALLOC[core mas alloc heap con asignador propio]
ALLOC --> STD[std heap mas sistema operativo]
style CORE fill:#a6e3a1,color:#11111b
style ALLOC fill:#cba6f7,color:#11111b
style STD fill:#89b4fa,color:#11111b

core no presupone nada. core más alloc presupone que existe un asignador, pero no un SO. std presupone las dos cosas. La programación de sistemas consiste, en buena medida, en elegir conscientemente el piso mínimo que tu entorno puede sostener.

Activar alloc y designar un asignador

Recuperar el montículo son dos pasos. El primero: nombrar el crate. alloc no se enlaza automáticamente en no_std ni está en el prelude, así que lo declaras de forma explícita con una de las pocas apariciones legítimas de extern crate que quedan en el Rust moderno:

#![no_std]
extern crate alloc;

use alloc::vec::Vec;
use alloc::string::String;
use alloc::boxed::Box;

El segundo paso es imprescindible: designar un asignador global. Sin él, en cuanto tu código intente asignar, el enlazado falla porque no hay ninguna rutina a la que llamar. Un asignador global es un static que implementa el trait GlobalAlloc, cuyo contrato son dos operaciones sobre punteros crudos:

use core::alloc::{GlobalAlloc, Layout};

struct MiAsignador;

unsafe impl GlobalAlloc for MiAsignador {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        // pedir layout.size() bytes con alineacion layout.align()
        // devolver el puntero al bloque, o null si no hay memoria
        todo!()
    }
    unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
        // liberar el bloque que encabeza ptr, del mismo layout
        todo!()
    }
}

#[global_allocator]
static ASIGNADOR: MiAsignador = MiAsignador;

El Layout transporta el tamaño y la alineación de lo que se pide. La implementación es unsafe porque devolver un puntero mal alineado o un bloque de tamaño equivocado es comportamiento indefinido. En la práctica rara vez la escribes a mano: en embebido usas crates como embedded-alloc sobre una región estática de RAM, y en un no_std hospedado puedes envolver el asignador del sistema. Con el asignador en su sitio, todo vuelve a funcionar:

fn construir() -> Vec<i32> {
    let mut v = Vec::new();   // ahora hay heap: Vec asigna sin problema
    v.push(1);
    v.push(2);
    v
}

Un detalle práctico: alloc no instala un prelude propio, así que cada tipo se importa por su ruta —alloc::vec::Vec, alloc::string::String— y las macros se traen con use alloc::{vec, format};. Es más verboso que en std, pero también más explícito: deja a la vista exactamente qué del montículo consume cada módulo.

Qué recuperas y qué no

alloc te devuelve un arsenal completo de tipos del montículo, pero no la librería entera:

La ausencia más sonada es HashMap, que se queda en std por el hasher aleatorio sembrado por el SO que ya viste. Con alloc usas BTreeMap, o traes hashbrown con un hasher determinista. Un último detalle operativo: cuando una asignación falla —el asignador devuelve null—, alloc enruta el fallo a un manejador de error de asignación. Desde Rust 1.68 hay un comportamiento por defecto en estable (aborta el proceso), y personalizarlo con #[alloc_error_handler] sigue siendo una característica de nightly.

Conviene subrayar que estos tipos no son primos pobres de los de std: son exactamente los mismos. El Vec que obtienes vía alloc es idéntico byte a byte al que usarías con std, porque std no lo reimplementa: lo reexporta desde alloc. La misma capacidad amortizada, el mismo crecimiento geométrico, la misma semántica de Drop. Lo único que cambia entre un servidor y un microcontrolador es quién provee los bytes; el comportamiento de la colección es invariante.

Un asignador global, o uno por colección

#[global_allocator] instala un asignador para todo el proceso: cada Box y cada Vec acuden a él. Es lo que casi siempre quieres en no_std. Pero existe un segundo mecanismo, aún inestable, pensado para casos exigentes: el trait Allocator (la feature allocator_api), que permite que cada colección lleve su propio asignador como parámetro de tipo.

// Con la feature inestable allocator_api, el asignador viaja en el tipo:
// let v: Vec<u8, MiArena> = Vec::new_in(arena);

La diferencia conceptual es honda. GlobalAlloc responde a la pregunta “de donde sale la memoria del programa”, una sola vez y para todo. Allocator responde a “de donde sale la memoria de esta estructura”, tantas veces como quieras: una arena por petición, un pool por subsistema, memoria de un dispositivo concreto. En estable te bastará casi siempre el asignador global; conocer el otro eje te dice hasta dónde llega el control fino cuando de verdad lo necesitas.