¿Por qué los programadores de C++ deberían evitar new? Optimización de código

«Why should C++ programmers minimize use of 'new'?»: analizando la pregunta icónica

Si alguna vez has visitado Stack Overflow en busca de respuestas sobre C++, seguramente has visto esta pregunta. Ha acumulado miles de votos y decenas de miles de visitas. Y no es casualidad. Para un principiante, el tema parece contraintuitivo: «¿Cómo es posible? En Java o C# escribo constantemente new y es normal. ¿Por qué en C++ de repente es malo?»

Hoy no solo traduciremos la respuesta del foro en inglés. Desglosaremos paso a paso por qué minimizar new en C++ no es un capricho de los gurús, sino una cuestión de rendimiento, seguridad y sentido común. Y sí, escribiremos código, veremos ensamblador (casi) y contaremos nanosegundos.

¿A dónde va la memoria? Pila vs Montón

Antes de hablar de new, recordemos los fundamentos. En C++ hay dos lugares principales para almacenar datos:

• Pila (stack) — pequeña, rápida, gestionada automáticamente. Tan pronto como una variable sale del ámbito, se destruye. Instantáneamente.
• Montón (heap) — grande, lento, requiere gestión manual. Para obtener memoria allí, se necesita llamar a new (o malloc). Para liberarla, delete.

Cada llamada a new no es solo «dame memoria». Es una llamada compleja al sistema, búsqueda de un bloque libre, actualización de estructuras de control. Es cientos de veces más lento que la asignación en la pila.

Ejemplo #1: Comparación de velocidad

#include <chrono>#include <iostream>#include <vector>

struct Point {    double x, y, z;};

int main() {    const int N = 1000000;

    // Asignación en pila (array en la pila)    auto start = std::chrono::high_resolution_clock::now();    Point points_stack[1000]; // 1000 objetos en la pila    auto end = std::chrono::high_resolution_clock::now();    std::cout << "Stack time: "               << std::chrono::duration_cast<std::chrono::nanoseconds>(end - start).count()              << " ns";

    // Asignación dinámica mediante new    start = std::chrono::high_resolution_clock::now();    std::vector<Point*> points_heap;    for (int i = 0; i < 1000; ++i) {        points_heap.push_back(new Point());    }    end = std::chrono::high_resolution_clock::now();    std::cout << "Heap (new) time: "               << std::chrono::duration_cast<std::chrono::nanoseconds>(end - start).count()              << " ns";

    // Limpiamos (¡obligatorio!)    for (auto p : points_heap) delete p;

    return 0;}

Resultado (en una máquina típica):

Stack time: 0 nsHeap (new) time: 45200 ns

Una diferencia de decenas de miles de veces. Por supuesto, es un ejemplo sintético, pero muestra claramente: cada new innecesario son microsegundos perdidos de su presupuesto de rendimiento.

El problema principal de new: fugas y fragmentación

Si solo fuera cuestión de velocidad, sería medio problema. Pero new trae consigo una serie de problemas:

1. Fugas de memoria (memory leaks)

¿Olvidaste llamar a delete? Felicidades, tienes una fuga. El programa funciona una hora, un día, una semana — y de repente falla con std::bad_alloc. Un clásico. Especialmente peligrosas son las fugas en procesos de larga duración (servidores, juegos, GUI).

2. Punteros colgantes (dangling pointers)

Eliminaste el objeto, pero el puntero permanece. Cualquier acceso a él es comportamiento indefinido (UB). El programa puede funcionar, puede fallar, puede cambiar tu música por techno. UB es malo.

3. Fragmentación del montón

Los frecuentes new/delete fragmentan el montón en pequeños trozos. Incluso si hay suficiente memoria, asignar un bloque grande se vuelve imposible. Esto se llama fragmentación externa.