De C a C++ — cuándo y por qué migrar tu motor

Publicado: 2026-07-28 | Por: Carlos Montiel | Lectura: ~4 minutos

A lo largo del curso mezclamos C y C++ libremente. Hoy formalizamos la pregunta: ¿cuándo vale la pena dar el salto completo, y qué se gana realmente al hacerlo?

Por qué esta pregunta importa

En la lección anterior optimizamos rendimiento, un área donde C y C++ suelen rendir de forma prácticamente idéntica cuando se usan bien — la velocidad no es la razón principal para migrar. La razón real para preferir C++ es la seguridad y la expresividad: menos oportunidades de bugs de memoria, código más fácil de mantener a medida que el proyecto crece, y abstracciones que no cuestan rendimiento en tiempo de ejecución ("abstracciones de costo cero").

Gestión manual de memoria: el mayor riesgo de C puro

En C, cada `malloc` necesita su `free` correspondiente, y es responsabilidad tuya rastrear cuándo. Un error aquí produce fugas de memoria o, peor, "use-after-free" (usar memoria ya liberada).

// C puro: responsabilidad manual total
typedef struct {
    int* posiciones_x;
    int cantidad;
} ListaEnemigosC;

ListaEnemigosC* crear_lista(int cantidad) {
    ListaEnemigosC* lista = (ListaEnemigosC*)malloc(sizeof(ListaEnemigosC));
    lista->posiciones_x = (int*)malloc(cantidad * sizeof(int));
    lista->cantidad = cantidad;
    return lista;
}

void destruir_lista(ListaEnemigosC* lista) {
    free(lista->posiciones_x); // si olvidas esta línea: fuga de memoria
    free(lista);               // si olvidas esta línea: otra fuga
}
// Y si alguien usa "lista" después de destruir_lista(): use-after-free.

RAII: el concepto que justifica C++ por sí solo

RAII (Resource Acquisition Is Initialization) es la idea de que un recurso (memoria, un archivo abierto, un socket) se adquiere en el constructor de un objeto y se libera automáticamente en su destructor. El compilador garantiza que el destructor se ejecute cuando el objeto sale de scope, sin importar cómo — incluso si hay una excepción o un `return` anticipado.

// C++: RAII con std::vector, que gestiona su propia memoria internamente
class ListaEnemigosCpp {
public:
    ListaEnemigosCpp(int cantidad) : posiciones_x(cantidad) {}
    // No hay destructor manual: std::vector libera su memoria automáticamente
private:
    std::vector<int> posiciones_x;
};

void usar_lista() {
    ListaEnemigosCpp lista(10);
    // ... usar lista ...
} // aquí, al salir de scope, la memoria se libera sola. Sin free(), sin fugas.

Lo mismo aplica a punteros individuales con `std::unique_ptr`, que ya usamos en la lección 7 para el `GestorEstados`:

// En vez de esto (C puro o C++ "a la antigua"):
Enemigo* e = new Enemigo();
// ... si algo falla antes del delete, fuga de memoria garantizada ...
delete e;

// Esto:
std::unique_ptr<Enemigo> e = std::make_unique<Enemigo>();
// se libera automáticamente al salir de scope, sin importar qué pase en el camino

Contenedores estándar vs. arrays manuales

En C, un array dinámico requiere gestionar manualmente el tamaño y la capacidad, y reimplementar el crecimiento cuando se llena. En C++, `std::vector` ya resuelve esto — y de forma probada, sin los bugs off-by-one típicos de una implementación casera.

// C: crecer un array dinámico manualmente
int* enemigos = (int*)malloc(4 * sizeof(int));
int capacidad = 4;
int cantidad = 0;

void agregar(int** arr, int* cap, int* cant, int valor) {
    if (*cant == *cap) {
        *cap *= 2;
        *arr = (int*)realloc(*arr, (*cap) * sizeof(int));
    }
    (*arr)[(*cant)++] = valor;
}

// C++: std::vector ya hace exactamente esto, probado y sin bugs
std::vector<int> enemigos;
enemigos.push_back(42); // crece automáticamente cuando hace falta

Cuándo NO vale la pena migrar

C++ no es estrictamente superior en todos los contextos. Hay razones legítimas para preferir C puro:

- Estás trabajando en un microcontrolador o entorno embebido con recursos extremadamente limitados, donde cada abstracción, aunque sea "de costo cero" en teoría, agrega complejidad al binario final. - Necesitas compatibilidad estricta con una API o SDK que expone únicamente una interfaz en C (esto es extremadamente común en librerías del sistema y drivers). - Tu equipo ya tiene una base de código en C grande y estable, y una migración parcial introduciría más riesgo del que resuelve.

Cómo migrar de forma incremental, sin reescribir todo

C++ es, en gran medida, un superconjunto de C — la mayoría del código en C compila directamente como C++. Esto permite una migración gradual, archivo por archivo, en vez de una reescritura total y arriesgada.

// 1. Cambia la extensión y el compilador (de .c/gcc a .cpp/g++), sin cambiar código todavía.
// 2. Compila y corrige los errores que C++ es más estricto en señalar
//    (por ejemplo, C++ exige casts explícitos que C permite implícitos):

// C permite esto sin cast:
int* p = malloc(sizeof(int) * 10);

// C++ exige el cast explícito:
int* p = (int*)malloc(sizeof(int) * 10);
// o, mejor, adopta directamente el estilo C++:
int* p = new int[10];

// 3. Convierte structs con funciones asociadas sueltas en clases con métodos:

// Antes (C):
typedef struct { float x, y; } Vector2;
Vector2 vector2_sumar(Vector2 a, Vector2 b) {
    return (Vector2){ a.x + b.x, a.y + b.y };
}

// Después (C++), mismo comportamiento, mejor organización:
struct Vector2 {
    float x, y;
    Vector2 operator+(const Vector2& otro) const {
        return { x + otro.x, y + otro.y };
    }
};

Un buen uso de tu asistente de IA para esta migración

Migrar código legado de C a C++ es exactamente el tipo de tarea mecánica y repetitiva donde un asistente de IA brilla, siempre que lo supervises de cerca. Pídele que migre un archivo a la vez (no el proyecto completo de una sola vez), que te muestre el diff exacto de cada cambio, y que te explique por qué cada `malloc`/`free` se reemplazó por su equivalente en C++. Revisa cada cambio de gestión de memoria con especial cuidado — es el área donde un error silencioso de la IA (o tuyo) tiene el mayor costo.

En la lección final vamos a tomar todo lo construido durante este curso y darle el último paso: empaquetarlo y publicarlo para que otras personas puedan jugarlo.

Carlos Montiel
Arquitecto de Soluciones IA Empresarial
Especialista en LLMs, Agentes y Orquestación
guatemalia.com/#contacto · info@guatemalia.com

← Volver al índice Siguiente artículo →