Співбесіда з C++ перевіряє три речі: чи розумієте ви обʼєктну модель, чи можна довірити вам памʼять і чи знаєте ви, чого коштує стандартна бібліотека. Нижче питання, які ставлять найчастіше, кожне з еталонною відповіддю.
До кожного питання — еталонна відповідь, з якою можна порівняти свою.
Посилання привʼязується при створенні й перепризначене бути не може; вказівник буває нульовим, перепризначається і має власну адресу та арифметику. На практиці посилання беруть, коли обʼєкт мусить існувати, а вказівник — коли відсутність є законним станом. Посилання не окремий обʼєкт, тому немає ні посилань на посилання, ні масивів із них.
Захоплення ресурсу є ініціалізацією: ресурсом володіє обʼєкт, захоплення відбувається в конструкторі, звільнення — у деструкторі. Оскільки деструктори виконуються на всіх шляхах виходу, включно з розкруткою стека винятком, ресурс неможливо втратити через ранній return, який хтось додав пізніше. Усі розумні вказівники, лок-гарди і файлові потоки стандартної бібліотеки — це вона.
unique_ptr — одноосібне володіння, переміщується, але не копіюється, і не коштує нічого понад сирий вказівник: він має бути вибором за замовчуванням. shared_ptr — спільне володіння з атомарним лічильником посилань, це не безкоштовно і часто береться там, де володіння просто не було продумане. weak_ptr спостерігає за shared_ptr, не володіючи ним, і головна його робота — розривати цикли, які інакше ніколи не звільняться.
Бо видалення похідного обʼєкта через вказівник на базовий без нього — невизначена поведінка, а на практиці деструктор нащадка просто не виконується і його поля витікають. Правило таке: якщо від класу збираються успадковуватися й видаляти поліморфно, деструктор віртуальний. Якщо клас не задуманий базовим, деструктор йому не потрібен, а доданий створює vtable, якої не було.
У класу з віртуальними функціями зʼявляється таблиця вказівників на функції — vtable, одна на клас, — а кожен обʼєкт зберігає прихований вказівник на неї, vptr. Віртуальний виклик читає vptr, індексує таблицю і стрибає. Звідси і зайвий вказівник у розмірі обʼєкта, і непрямість виклику, і те, що компілятор здатен девіртуалізувати виклик лише коли може довести динамічний тип.
Стек виділяється і звільняється зсувом вказівника при вході і виході з області видимості: він швидкий, неперервний і дружній до кешу, але обмежений і привʼязаний до часу життя. Купа виділяється на запит, власних правил часу життя не має і коштує реального виклику алокатора плюс ризику фрагментації. За замовчуванням беруть стек, а в купу йдуть, коли розмір невідомий або обʼєкт має пережити область видимості.
Move-семантика дозволяє передати ресурс замість копіювання: move-конструктор вектора забирає вказівник на буфер, а не виділяє памʼять і копіює елементи. Сам std::move нічого не переміщує — це зведення до rvalue-посилання, яке робить обʼєкт придатним для переміщення. Чи переміститься щось, залежить від наявності в типу move-конструктора, а обʼєкт-джерело лишається валідним, але з невизначеним вмістом.
Поведінка, на яку стандарт не накладає вимог: вихід за межі масиву, розіменування нуля, переповнення знакового, некоректна робота з переміщеним обʼєктом, гонка даних. Небезпечна вона саме тим, що часто виглядає робочою: компілятор має право вважати, що цього не стається, і оптимізувати виходячи з цього, тому той самий код ламається після стороннього змінення або іншого рівня оптимізації. Шукають її санітайзерами.
Майже завжди вектор. vector неперервний, тому обхід дружній до кешу і передвибірки, а list ганяється за вказівником на кожному елементі й платить виділення на вузол. list виграє лише коли ви постійно вставляєте в середину або сплайсите і тримаєте ітератори, які мусять лишатися валідними, — і навіть тоді варто поміряти, бо на сучасному залізі локальність зазвичай бʼє кращу асимптотику.
Два потоки звертаються до однієї комірки памʼяті, хоча б один пише, і між ними немає синхронізації — це невизначена поведінка, а не просто невірний результат. Уникають її, не розділяючи змінюваний стан, або захищаючи його мʼютексом, або роблячи доступ атомарним. ThreadSanitizer знаходить більшість таких місць, і це надійніше за міркування про розклад, який ви не можете відтворити.
На співбесіді ти говориш вголос під тиском. Кем поставить ті самі питання, оцінить кожну відповідь і покаже, що саме підтягнути.
Пройти інтерв'ю C++ →