Herramientas, concurrencia y proyecto final
Cómo compila C++, el linker, Make y CMake, bibliotecas, sanitizers, depurar, hilos y mutex, las Core Guidelines y tu proyecto final.
13 aulas · 12 horas de práctica · en el navegador, sin instalar nada
Temario
- Cómo compila C++: preprocesador, compilador, linker — Entre tu código y el programa hay una línea de montaje de tres etapas: el preprocesador pega texto, el compilador traduce cada .cpp por separado y el linker junta los pedazos. Armás un modelo de cada una.
- Errores del linker — undefined reference, multiple definition, una firma que no coincide, una global sin definir y dos main: los errores del linker parecen crípticos y son siempre la misma pregunta: ¿quién define este símbolo?
- Make: tu propio mini-make — Recompilar todo cada vez es lento. Make sabe qué depende de qué, construye en el orden justo y rehace solo lo que cambió. Escribís el algoritmo que tiene adentro: un recorrido en postorden con fechas.
- CMake — Nadie escribe Makefiles a mano en un proyecto grande: se describe el proyecto con targets y CMake genera el build. Armás un mini-CMake que lee add_library, add_executable, target_link_libraries y target_include_directories.
- Bibliotecas estáticas y dinámicas — Una biblioteca es código compilado para reusar. La estática se copia adentro de cada programa al linkear; la dinámica se carga cuando el programa arranca. Modelás qué saca el linker de un .a, por qué importa el orden de los -l, qué versión corre cada uno y cómo busca el cargador un .so.
- Comportamiento indefinido y sanitizers — En C++ hay errores que no tienen un resultado "malo": no tienen ningún resultado definido. Overflow con signo, salirse de un arreglo, un puntero nulo, usar memoria liberada, una función sin return. Los sanitizers los atrapan, y el motor del aula corre con uno.
- Depurar como un profesional — Depurar no es mirar el código hasta que algo salte. Es un método: reproducir, achicar, ubicar y confirmar. Bisección de versiones, assert, casos mínimos, trazas por cerr, aislar la entrada que rompe, y para qué sirve un depurador como gdb.
- Hilos — Un hilo es una tarea que corre a la par de otras. Quién avanza en cada momento lo decide el planificador del sistema operativo, no tu código. Simulás un planificador (ronda, quantum, tareas que esperan, prioridades) y ves cómo el mismo código termina distinto según el orden.
- mutex y condiciones de carrera — Dos cocineros, un pizarrón y una sartén. Si los dos anotan a la vez, se pierden platos: es una condición de carrera, y pasa porque cocina[plato]++ no es un paso sino tres. La provocás, la arreglás con un mutex, te trabás en un deadlock y salís, y conocés atomic.
- C++ Core Guidelines — C++ te deja hacer casi todo, y no todo conviene. Las Core Guidelines (Stroustrup y Sutter) dicen qué usar: nada de new desnudo, todo inicializado, sin casts de C, lo caro por const&, sin using namespace en headers. Escribís un mini-linter que las revisa, como clang-tidy.
- C++ en la industria: motores, embebidos, finanzas — Dónde se usa C++ de verdad y qué problemas resuelve en cada lugar: el orden de dibujado y el presupuesto de 16 ms de un motor de juegos, el buffer circular y el planificador de tiempo real de un microcontrolador, y el libro de órdenes de una bolsa. Lo que se corrige es un orden, y la torre lo hace aterrizar.
- Proyecto final I: el intérprete de comandos del robot — El robot del depósito entiende un lenguaje propio: AVANZAR, GIRAR, REPETIR, DEFINIR y LLAMAR. Escribís su intérprete de punta a punta: leer cada orden, girar con un enum, no caerse ante una orden mal escrita, bloques anidados con recursión y procedimientos guardados en un map.
- Proyecto final II: tu juego completo — Defendé la ciudad: rocas que caen del cielo, una nave que dispara, vidas, game over y récord. Un juego entero, de la primera línea al "jugar de nuevo", armado por etapas y jugable con el teclado.