to the top
close form
Для получения триального ключа
заполните форму ниже
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
Мне интересно попробовать плагин на:
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

close form
check circle
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
>
Глубина кроличьей норы или собеседовани…

Глубина кроличьей норы или собеседование по C++ в компании PVS-Studio

Хочется поделиться интересной ситуацией, когда вопрос, используемый нами на собеседовании, оказался сложнее, чем задумывал его автор. С языком C++ и компиляторами надо всегда быть начеку. Не заскучаешь.

0722_job_interview_ru/image1.png

Как и в любой другой программистской компании, у нас есть наборы вопросов для собеседования на вакансии разработчиков на языках C++, C# и Java. Многие вопросы у нас с двойным или тройным дном. За вопросы по C# и Java мы точно сказать не можем, так как у них другие авторы. Но многие вопросы, составленные Андреем Карповым для собеседований по C++, точно сразу задумывались, чтобы прощупать глубину знания особенностей языка.

На эти вопросы можно дать простой правильный ответ. Можно поглубже, и ещё глубже. В зависимости от этого при собеседовании мы определяем, насколько человек знаком с нюансами языка. Это для нас важно, так как мы разрабатываем анализатор кода и должны очень хорошо понимать языковые тонкости и "приколы".

Сегодня расскажем маленькую историю, как один из первых задаваемых вопросов на собеседовании оказался ещё более глубоким, чем мы планировали. Итак, мы показываем вот такой код:

void F1()
{
  int i = 1;
  printf("%d, %d\n", i++, i++);
}

и спрашиваем: "Что будет напечатано?".

Хороший вопрос. Сразу много может сказать про знания. Случаи, когда человек вообще не может на него ответить, рассматривать не будем. Такие отсеиваются ещё предварительным тестированием на сайте HeadHunter (hh.ru). Хотя, нет, враки. На нашей памяти была пара уникальных личностей, которые отвечали что-то в духе:

Этот код напечатает в начале процент, потом d, потом ещё процент, d, потом палочку, n, и затем две единицы.

Ясно, что в подобных случаях собеседование быстро заканчивается.

Итак, теперь вернемся к нормальным собеседованиям :). Нередко отвечают так:

Распечатается 1 и 2.

Это ответ уровня стажёра. Да, такие значения могут, конечно, распечататься, но мы ждем приблизительно следующего ответа:

Нельзя сказать, что именно распечатает этот код. Это неуточнённое (или неопределённое) поведение. Порядок вычисления аргументов не определён. Все аргументы должны быть вычислены до выполнения тела вызываемой функции, но вот в каком порядке это будет происходить, оставлено на усмотрение компилятора. Поэтому код вполне может распечатать как "1, 2", так и наоборот "2, 1". Вообще такой код писать крайне нежелательно, если он собирается как минимум двумя компиляторами, можно и "в ногу выстрелить". И многие компиляторы выдадут здесь предупреждение.

Действительно, если использовать Clang, то можно получить "1, 2".

А если использовать GCC, то можно получить "2, 1".

Когда-то давно мы пробовали компилятор MSVC, и он тоже выдавал "2, 1". Ничего не предвещало беды.

Недавно для вообще сторонней цели вновь понадобилось скомпилировать этот код с помощью современного Visual C++ и запустить. Собирали под конфигурацию Release с включенной оптимизацией /O2. И, как говорится, нашли приключения на свою голову :). Как думаете, что получилось? Ха! Вот что: "1, 1".

Вот и думай что хочешь. Оказывается, что вопрос ещё глубже и запутаннее. Мы сами не ожидали, что такое может быть.

Поскольку стандарт C++ никак не регламентирует порядок вычисления аргументов, компилятор интерпретирует данный вид неуточненного поведения очень своеобразным образом. Давайте взглянем на ассемблерный код, генерируемый компилятором MSVC 19.25 (Microsoft Visual Studio Community 2019, Version 16.5.1), флаг версии стандарта языка '/std:c++14':

0722_job_interview_ru/image2.png

Формально, оптимизатор превратил код выше в следующий:

void F1()
{
  int i = 1;
  int tmp = i;
  i += 2;
  printf("%d, %d\n", tmp, tmp);
}

С точки зрения компилятора, такая оптимизация не меняет наблюдаемого поведения программы. Глядя на это, начинаешь понимать, что неспроста стандарт C++11 кроме умных указателей добавил также "волшебную" функцию make_shared (а C++14 добавил еще и make_unique). Такой безобидный пример, а тоже может "наломать дров":

void foo(std::unique_ptr<int>, std::unique_ptr<double>);

int main()
{
  foo(std::unique_ptr<int> { new int { 0 } },
      std::unique_ptr<double> { new double { 0.0 } });
}

Хитрый компилятор может превратить это в следующий порядок вычислений (тот же MSVC, например):

new int { .... };
new double { .... };
std::unique_ptr<int>::unique_ptr
std::unique_ptr<double>::unique_ptr

Если второй вызов оператора new бросит исключение, то мы получаем утечку памяти.

Но вернёмся к изначальной теме. Несмотря на то, что с точки зрения компилятора все хорошо, мы всё равно были уверены, что вывод "1, 1" некорректно считать ожидаемым разработчиком поведением. И тогда мы попробовали скомпилировать исходный код компилятором MSVC с флагом версии стандарта '/std:c++17'. И всё начинает работать так, как и ожидалось, и печатается "2, 1". Взглянем на ассемблерный код.:

0722_job_interview_ru/image4.png

Все честно, компилятор передал в качестве аргументов значения 2 и 1. Но почему все так разительно поменялось? Оказывается, в стандарт C++17 было дописано следующее:

The postfix-expression is sequenced before each expression in the expression-list and any default argument. The initialization of a parameter, including every associated value computation and side effect, is indeterminately sequenced with respect to that of any other parameter.

Компилятор все так же имеет право вычислять аргументы в произвольном порядке, но теперь, начиная со стандарта C++17, к вычислению следующего аргумента и его побочным эффектам имеет право приступить лишь с того момента, как будут выполнены все вычисления и побочные эффекты предыдущего аргумента.

Кстати, если тот же пример с умными указателями скомпилировать с флагом '/std:c++17', то и там все становится хорошо – использовать std::make_unique теперь необязательно.

Вот такое ещё одно измерение глубины в вопросе выяснилось. Бывает теория, а бывает практика в виде конкретного компилятора или разной трактовки стандарта :). Мир C++ всегда сложнее и неожиданнее, чем кажется.

Если кто-то сможет более точно объяснить происходящее, то просим рассказать в комментариях. Должны же мы окончательно разобраться в вопросе, чтобы хотя бы самим знать ответ на него на собеседовании! :)

Вот такая познавательная история. Надеемся, было занятно, и вы поделитесь своим мнением по этой теме. И советуем использовать как можно более современный стандарт языка, чтобы меньше удивляться тому, что могут нынешние оптимизирующие компиляторы. А еще лучше – вообще не пишите подобный код :).

P.S. Можно сказать, что мы "засветили вопрос", и теперь его придётся удалить из вопросника. Не видим в этом смысла. Если человек не поленился перед собеседованием изучить наши публикации, прочитает этот материал и потом использует, то он молодец и заслуженно получит плюсик :).

Популярные статьи по теме
Под капотом SAST: как инструменты анализа кода ищут дефекты безопасности

Дата: 26 Янв 2023

Автор: Сергей Васильев

Сегодня речь о том, как SAST-решения ищут дефекты безопасности. Расскажу, как разные подходы к поиску потенциальных уязвимостей дополняют друг друга, зачем нужен каждый из них и как теория ложится на…
Ложные представления программистов о неопределённом поведении

Дата: 17 Янв 2023

Автор: Гость

Неопределённое поведение (UB) – непростая концепция в языках программирования и компиляторах. Я слышал много заблуждений в том, что гарантирует компилятор при наличии UB. Это печально, но неудивитель…
Топ-10 ошибок в C++ проектах за 2022 год

Дата: 29 Дек 2022

Автор: Владислав Столяров

Дело идёт к Новому году, а значит, самое время традиционно вспомнить десять самых интересных срабатываний, которые нашёл PVS-Studio в 2022 году.
PVS-Studio и RPCS3: лучшие предупреждения в один клик

Дата: 12 Дек 2022

Автор: Александр Куренев

Best Warnings — режим анализатора, оставляющий в окне вывода 10 лучших предупреждений. Мы предлагаем вам ознакомиться с обновлённым режимом Best Warnings на примере проверки проекта RPCS3.
Holy C++

Дата: 23 Ноя 2022

Автор: Гость

В этой статье постараюсь затронуть все вещи, которые можно без зазрения совести выкинуть из С++, не потеряв ничего (кроме боли), уменьшить стандарт, нагрузку на создателей компиляторов, студентов, из…

Комментарии (0)

Следующие комментарии next comments
close comment form
Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо