Abstracciones de costo cero (y dónde leakéan)

"Zero-cost abstraction" no significa "las abstracciones son gratis". Significa que C++ intenta que la maquinaria de abstracción no usada no cueste nada, y que la maquinaria usada compile a código tan bueno como una versión lower-level escrita a mano. Templates, inlining, RAII, std::span y muchos algorithms de la STL pueden hacer eso. El leak es que algunas decisiones de diseño necesariamente crean hechos de runtime: allocation, virtual dispatch, type erasure, reference counting, metadata de exceptions, tamaño de código y cache misses.

El reset: zero-cost es un claim sobre código generado para una abstracción concreta. Verificalo a nivel assembly, allocation y cache.

Cómo funciona de verdad

C++ tiene varios mecanismos de abstracción que desaparecen bien cuando el optimizer tiene suficiente información:

El optimizer no es magia. Necesita visibilidad, hechos de aliasing, control flow simple y un ABI objetivo. Un template chico que recibe una lambda puede inlinear dentro del caller y volverse el mismo loop que hubieras escrito en C. Un parámetro std::function normalmente no puede hacer eso: type-erasea el callable detrás de una llamada indirecta y puede alocar para captures grandes. Virtual dispatch preserva runtime polymorphism de forma similar con una llamada vía vtable salvo que el compilador pueda devirtualizar. Las exceptions pueden tener costo casi cero en el camino no-throwing en algunos ABIs, pero igual influyen en metadata binaria, layout de código y qué pasa cuando se lanza una excepción.

Acá la historia de "C++ te deja escribir código high-level" se encuentra con el modelo de máquina de las ramas anteriores. La CPU todavía ejecuta loads, stores, branches, calls y cache misses. El linker todavía ve símbolos. El allocator todavía sirve pedidos de heap. El ABI todavía decide cómo funcionan virtual calls, exception handling y object layout.

Artefacto ejecutable: comparar C, templates, type erasure y virtual dispatch

El demo ejecutable vive en examples/modern-cpp/zero-cost-abstractions-and-where-they-leak/. Construye un baseline C y una versión C++ que usa std::span, una projection template, std::function y una interfaz virtual.

cd examples/modern-cpp/zero-cost-abstractions-and-where-they-leak
./run.sh

El baseline C es exactamente el loop low-level:

static int square_sum_c(IntSlice slice) {
    int total = 0;
    for (size_t i = 0; i < slice.count; ++i) {
        int value = slice.items[i];
        total += value * value;
    }
    return total;
}

La versión C++ template expresa la operación genéricamente:

template <typename T, typename Projection>
static T sum_projected(std::span<const T> values, Projection project) {
    T total{};
    for (T value : values) {
        total += project(value);
    }
    return total;
}

auto square = [](int value) {
    return value * value;
};

A -O2, la versión template/lambda tiene buenas chances de volverse el mismo loop básico que la función C porque el tipo y cuerpo del callable son visibles. El mismo demo también incluye:

static int sum_with_function(std::span<const int> values,
                             const std::function<int(int)> &project);

struct Cost {
    virtual ~Cost() = default;
    virtual int value() const = 0;
};

Esas abstracciones son intencionalmente de otra clase. std::function es type erasure; las virtual functions son runtime dispatch. A veces ese es el diseño correcto. Simplemente no es gratis del mismo modo en que puede serlo un template visible. El script escribe c_manual.O2.s y demo.O2.s; comparalos localmente o pegá las funciones en Compiler Explorer.

Dónde leakéa la abstracción

• Allocation leakéa. std::vector, std::string, std::make_shared y callables type-erased pueden alocar. La abstracción puede ser limpia, pero el allocator y la cache siguen importando.
• Dispatch leakéa. Virtual calls, function pointers y std::function pueden convertirse en llamadas indirectas que bloquean inlining y prediction.
• El tamaño de código leakéa. Templates pueden instanciar muchas copias. Más código puede lastimar instruction cache aunque cada specialization sea rápida.
• Error handling leakéa. Exceptions, RTTI y unwind metadata afectan layout binario y flags de build, especialmente en kernels o entornos freestanding.
• Layout leakéa. Una jerarquía de clases prolija puede dispersar objetos por el heap. Data-oriented layout puede ganarle a una forma object-oriented en hot loops.
• Compile time leakéa. Templates pesados en headers mueven trabajo de runtime a build time. Puede ser el trade correcto, pero sigue siendo un costo.

Fallas típicas y trade-offs

• Confiar en el slogan. "Zero-cost" no es prueba. Medí assembly, allocations, cache misses, branch misses y tamaño de binario cuando importa.
• Sobre-abstraer el hot path. Un callback type-erased en una ruta fría de configuración está bien. El mismo callback en un loop por paquete puede dominar runtime.
• Olvidar bordes ABI. Los templates no forman interfaces binarias estables. Las interfaces virtuales sí, pero te comprometen con decisiones de layout y dispatch.
• Los debug builds mienten distinto. Inlining y optimización pueden estar ausentes. Debug iterator checks y capas de abstracción pueden parecer mucho más caras que en release.
• Los microbenchmarks también pueden mentir. Un loop chico puede inlinear perfecto solo y comportarse distinto dentro de un binario real con presión de cache y datos impredecibles.

En la práctica

• Escribí primero la abstracción clara, después inspeccioná. Si el código generado es el mismo, quedate con el código más claro. Si no, decidí si el costo está en el camino que importa.
• Preferí compile-time polymorphism en código genérico hot. Templates, concepts y lambdas mantienen visible el tipo concreto.
• Usá runtime polymorphism cuando la elección de runtime es real. Virtual dispatch y std::function son buenas herramientas cuando necesitás substitución entre comportamiento compilado separado o elegido dinámicamente.
• Mantené visibles ownership y layout. std::span es una view, std::vector es ownership contiguo, std::list son nodos y std::shared_ptr es reference counting. El tipo debería recordarte el costo de máquina.
• Usá las mismas herramientas que en C. Compiler Explorer, -S, nm, profilers, sanitizers y pensamiento cache-aware siguen aplicando.

Conecta con: Templates y generic programming · La STL: containers, iterators, algorithms · C vs C++: qué ganás de verdad (y qué pagás) · Optimización: qué hace -O2 con tu código · Data layout y cache-friendliness · Object files y qué hay adentro · El dynamic loader, relocation, PLT y GOT

Fuentes

• C++ Core Guidelines - marco del zero-overhead principle y guía de performance/resource management para C++ moderno. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
• Bjarne Stroustrup - A Tour of C++ - panorama conciso del lenguaje y las abstracciones de biblioteca estándar sobre las que se apoya esta rama. https://www.stroustrup.com/tour3.html
• cppreference - Templates - modelo de instantiation que vuelve concreta la abstracción de compile time. https://en.cppreference.com/w/cpp/language/templates
• cppreference - Virtual functions - modelo de dynamic dispatch y cuándo el comportamiento overriding se selecciona en runtime. https://en.cppreference.com/w/cpp/language/virtual
• cppreference - std::function - wrapper de callable type-erased y su semántica de storage de callables. https://en.cppreference.com/w/cpp/utility/functional/function
• cppreference - Exceptions - modelo de exception handling y stack unwinding que puede afectar código generado y metadata binaria. https://en.cppreference.com/w/cpp/language/exceptions
• Ulrich Drepper - What Every Programmer Should Know About Memory - realidad de cache y sistema de memoria detrás de costos de abstracción. https://akkadia.org/drepper/cpumemory.pdf
• Compiler Explorer - inspeccioná si una abstracción específica optimiza al machine code esperado. https://godbolt.org/