Las entrevistas de C++ evalúan tres cosas: si entiendes el modelo de objetos, si se te puede confiar la gestión de memoria, y si sabes qué cuesta realmente la biblioteca estándar. Aquí están las preguntas más frecuentes, cada una con una respuesta modelo.
Cada pregunta viene con una respuesta modelo con la que puedes comparar la tuya.
Una referencia debe vincularse al crearse y nunca puede revincularse; un puntero puede ser null, reasignarse, y tiene su propia dirección y aritmética. En la práctica tomas una referencia cuando la cosa debe existir y un puntero cuando la ausencia es un estado válido. Una referencia no es un objeto separado, por eso no hay referencias a referencias ni arrays de ellas.
Resource acquisition is initialization: un recurso es propiedad de un objeto, se adquiere en su constructor y se libera en su destructor. Como los destructores corren en cada camino de salida — incluyendo una excepción desenrollando el stack — el recurso no puede filtrarse por un return temprano que alguien agregó después. Cada smart pointer, lock guard y file stream de la biblioteca estándar es esta idea.
unique_ptr es propiedad exclusiva, se mueve pero no se copia, y no cuesta nada más que un puntero crudo — debería ser el default. shared_ptr es propiedad compartida con un contador de referencias atómico, que no es gratis y al que a menudo se recurre cuando la propiedad simplemente no se decidió. weak_ptr observa a un shared_ptr sin poseerlo, y su trabajo principal es romper ciclos de referencias que de otro modo nunca se liberarían.
Porque eliminar un objeto derivado a través de un puntero base sin uno es comportamiento indefinido — en la práctica el destructor derivado nunca corre y sus miembros se filtran. La regla es: si una clase está pensada para ser heredada y eliminada polimórficamente, su destructor es virtual. Si no está pensada para ser base, no lo necesita, y dárselo agrega una vtable que no tenía.
Una clase con funciones virtuales obtiene una tabla de punteros a función — la vtable — una por clase, y cada objeto de ella guarda un puntero oculto a esa tabla, el vptr. Una llamada virtual lee el vptr, indexa la tabla, y salta. Eso es lo que hace al objeto más grande en un puntero y la llamada indirecta, y por eso el compilador solo puede desvirtualizar cuando puede probar el tipo dinámico.
El stack se asigna y libera moviendo un puntero al entrar y salir de los scopes, así que es rápido, contiguo y amigable con la caché, pero limitado y atado al lifetime. El heap se asigna bajo demanda, no tiene reglas de lifetime propias, y cuesta una llamada real al allocator más el riesgo de fragmentación. Prefiere el stack; ve al heap cuando el tamaño es desconocido o el objeto debe sobrevivir al scope.
Move semantics permite transferir un recurso en lugar de copiarlo — el constructor de movimiento de un vector roba el puntero del buffer en lugar de asignar y copiar elementos. std::move en sí no mueve nada: es un cast a una referencia rvalue que hace al objeto elegible para un move. Que algo se mueva depende de que el tipo tenga un constructor de movimiento, y el objeto del que se movió queda válido pero no especificado.
Comportamiento sobre el que el estándar no impone requisitos — leer más allá del final de un array, desreferenciar null, overflow con signo, usar incorrectamente un objeto del que se movió, un data race. Es peligroso precisamente porque a menudo parece funcionar: el compilador puede asumir que nunca ocurre y optimizar bajo esa suposición, así que el mismo código se rompe tras un cambio no relacionado o un nivel de optimización distinto. Los sanitizers son cómo se encuentra.
Casi siempre. vector es contiguo, así que la iteración es amigable con la caché y prefetcheable, mientras list persigue un puntero por elemento y paga una asignación por nodo. list solo gana cuando haces splice o insertas en el medio constantemente y mantienes iteradores que deben seguir siendo válidos — e incluso entonces vale la pena medir, porque en hardware moderno la localidad suele vencer a la mejor clase de complejidad.
Dos hilos accediendo a la misma ubicación de memoria, al menos uno escribiendo, sin sincronización entre ellos — eso es comportamiento indefinido, no simplemente un resultado incorrecto. Se evita no compartiendo estado mutable, o protegiéndolo con un mutex, o haciendo el acceso atómico. ThreadSanitizer encuentra la mayoría, lo cual es más confiable que razonar sobre un scheduling que no puedes reproducir.
En una entrevista real hablas bajo presión. Cam hace estas mismas preguntas, evalúa cada respuesta y muestra exactamente qué mejorar.
Practicar entrevista de C++ →