Здравствуйте, Тёмчик, Вы писали:

Тё>Плюсник утверждает, что даже такая простая вещь, как динамический массив- в плюсах реализована очень сложно?

Я утверждаю, что std::vector — это намного больше, чем динамический массив.
Если бы я был программисто на Rust, то рассказывал бы, как сложна реализация двусвязного списка.

Здравствуйте, Тёмчик, Вы писали:
Тё>Плюсник утверждает, что даже такая простая вещь, как динамический массив- в плюсах реализована очень сложно?
в С++ даже подсчет среднего двух чисел — неочевидная задача, а уж тем более динамический массив

__>в С++ даже подсчет среднего двух чисел — неочевидная задача, а уж тем более динамический массив
Да ладно, ничего сложного

int avg (int si_a, int si_b)
{
    if ((si_b > 0) && (si_a > (INT_MAX - si_b)))
    {
      if (si_a >= si_b)
        return si_b + (si_a - si_b) / 2;
      else
        return si_a + (si_b - si_a) / 2;
    } 
    else if ((si_b < 0) && (si_a < (INT_MIN - si_b)))
    {
      if (si_a <= si_b)
        return si_b + (si_a - si_b) / 2;
      else
        return si_a + (si_b - si_a) / 2;
    }
    else
    {
      return (si_a + si_b) / 2;
    }
}

Здравствуйте, Тёмчик, Вы писали:

PM>>Как бы вы ответили, например на вопрос "Должен ли shared_ptr быть потокобезопасным. И если да, то какой memory_order использовать для счетчика ссылок?"
Тё>Нет, не должен.
Тё>Что вы понимаете под memory order? Вы хотели сказать, memory barrier? В общем случае, не нужно делать потокобезопасным, по причине что memory barrier небесплатен.

no hire

Тё>Что вы понимаете под memory order?

В плюсы завезли memory model https://en.cppreference.com/w/cpp/language/memory_model

https://en.cppreference.com/w/cpp/atomic/memory_order
memory order соответсвенно определяет что должны/могут видеть разные потоки в конкретный момент времени

PM>>

PM>>int main()
PM>>{
PM>>    my_vector<std::string> vec;
PM>>    vec.push_back("hallo welt! the string is longer than 24 characters to run over SSO"); 
PM>>    for (int i = 0; i <1000; ++i)
PM>>    {
PM>>        vec.push_back(vec[0]);
PM>>    }
PM>>}
PM>>

Тё>В чём запинка?

Тут много может быть сюрпризов. Ну например, такой вариант некорректной работы. vec[0] возвращает ссылку (https://en.cppreference.com/w/cpp/container/vector/operator_at) на нулевой объект, далее его нужно вставить в вектор. Во время push_back вы видите, что нижележащий массив мал по размеру, вы создаете новый большего размера, а старую память отпускаете (и ее в этот момент кто-то начинает использовать в своих целях). После этого вы начинаете вставлять в новый массив то, что находится по ссылке vec[0]. Но проблема в том, что там сейчас могут быть совсем другие данные. И подобных нюансов, я уверен, сотни. Не даром эти контейнеры десятилетиями вылизывают.

PM>Как бы вы ответили, например на вопрос "Должен ли shared_ptr быть потокобезопасным. И если да, то какой memory_order использовать для счетчика ссылок?"

Дюже неприятно стало когда представил, что у меня такое на собеседовании спрашивают Гадость просто

Здравствуйте, Максим, Вы писали:

Тё>>Что вы понимаете под memory order?

М>В плюсы завезли memory model https://en.cppreference.com/w/cpp/language/memory_model

М>https://en.cppreference.com/w/cpp/atomic/memory_order
М>memory order соответсвенно определяет что должны/могут видеть разные потоки в конкретный момент времени

Ну т.е. это memory barrier. Я не совсем понимаю, почему название для плюсов выбрали такое неочевидное, ну да ладно.

Здравствуйте, Максим, Вы писали:


М>И подобных нюансов, я уверен, сотни. Не даром эти контейнеры десятилетиями вылизывают.
Баги бывают. Это не значит, что первую реализацию вектора писали лучшие умы человечества многие годы. Степанов может быть, за пару часов накидал со всеми контрактами. А дальше уже баги исправлялись по мере их выявления.

М>Дюже неприятно стало когда представил, что у меня такое на собеседовании спрашивают Гадость просто
Поговорить о memory barrier всегда полезно. Это фича (машинная инструкция) мульти-процовых систем: пометить область памяти, что изменения в ней должны быть из кеша одного исполнительного блока спроецированы на другие исполнительные блоки.

Здравствуйте, Тёмчик, Вы писали:

PM>>Как бы вы оценили свои знания C++ по 10-бальной шкале, где 0 — не знаю совсем?
Тё>В бытность мою плюсником 9/10.

Похвально но я же не HR, передо мной не надо выделяться на фоне индийских ребят с 10/10. Обычно при ответе на такой вопрос, я всегда вспоминаю про такой слайд из замечательной презентации Deep C (And C++):


PM>>Если кандидат начнет писать на собеседовании вектор с учетом всех этих вещей, то ему и дня может не хватить. Вообще, есть утверждение, что невозможно реализовать std::vector, оставаясь в рамках стандарта C++, т.к. некторые вещи можно сделать только компиляторо-/платформо- зависимым способом.
Тё>Что это за C++ программисты такое пошли беспомощные?

Это называется опыт, который приходит с годами взамен студенческого ковбойства.

PM>>Там уже в конструкторе cowinotrid есть OOM, и ошибка которую никто не заметил. Про удвоение емкости при нехватке места нет никаких гарантий, емкость может увеличиваться любым способом.
Тё>Ну извините, вы вывалили кучку жидкого кала, и предлагаете найти в нем все ошибки? Насчёт удвоения capacity- это обычная практика, для улучшения amortized complexity.

Про аттракцион "найди все ошибки в коде" в этой теме вообще не было речи. Я привел идею тестового случая для проверки вашей будущей реализации vector. Вы знакомы с понятием модульного тестирования? Когда для какого-то кода пишется тест, проверяющий корректность реализации.

Про стратегию роста динамических контейнеров пусть теоретики спорят, но в википедии пишут, что в Java ArrayList используется 1.5, что как бы ближе к теоретическому идеалу 𝜑

PM>>Но для вас же это не сложнее переворота строки и вы сможете реализовать минимальный аналог std::vector который пройдет такой тест?
PM>>

PM>>int main()
PM>>{
PM>>    my_vector<std::string> vec;
PM>>    vec.push_back("hallo welt! the string is longer than 24 characters to run over SSO"); 
PM>>    for (int i = 0; i <1000; ++i)
PM>>    {
PM>>        vec.push_back(vec[0]);
PM>>    }
PM>>}
PM>>

Тё>В чём запинка? Если не вдаваться в move semantics, которую я уже не застал- вызвать копирующие конструкторы (через оператор "=". Возможно, какой-нить std::move нагуглить. Важно же найти сообразительность, а не зазубренность API

Так и в чем запинка? "Talk is cheap. Show me the code.” Покажите реализацию класса my_vector, проходящего тест выше. Публичный интерфейс пусть будет таким:

template<typename T>
class my_vector
{
public:
   vector(); // default initial state: size() == 0, capacity() == 0

   ??? size();
   ??? capacity();
   
   ??? operator[](??? index);

   ??? push_back(???);
};

Вместо вопросов используйте подходящие типы. Дополнительные баллы если my_vector можно будет использовать в стиле C++11 т.е. так:

my_vector<int> vec{ 1, 2 3 };
int sum = 0;
for (auto&& x : vec) sum += x;
std::cout << sum;

PM>>Как бы вы ответили, например на вопрос "Должен ли shared_ptr быть потокобезопасным. И если да, то какой memory_order использовать для счетчика ссылок?"
Тё>Нет, не должен.

Скорее всего, после такого ответа будет итоговое "Спасибо, мы вам перезвоним."

Тё>Что вы понимаете под memory order? Вы хотели сказать, memory barrier? В общем случае, не нужно делать потокобезопасным, по причине что memory barrier небесплатен.

Нет, я хотел сказать memory_order, кандидат знающий C++ на 9/10 меня бы понял. Хотя, из-за безаппеляционности выделенного, я бы в этом начал сомневаться.

Здравствуйте, Максим, Вы писали:

Тё>>В чём запинка?

М>Тут много может быть сюрпризов. Ну например, такой вариант некорректной работы. vec[0] возвращает ссылку (https://en.cppreference.com/w/cpp/container/vector/operator_at) на нулевой объект, далее его нужно вставить в вектор. Во время push_back вы видите, что нижележащий массив мал по размеру, вы создаете новый большего размера, а старую память отпускаете (и ее в этот момент кто-то начинает использовать в своих целях). После этого вы начинаете вставлять в новый массив то, что находится по ссылке vec[0]. Но проблема в том, что там сейчас могут быть совсем другие данные. И подобных нюансов, я уверен, сотни. Не даром эти контейнеры десятилетиями вылизывают.

В точку! И насколько я помню, такой баг реально исправляли не так давно в какой-то из реализаций.

PM>>Как бы вы ответили, например на вопрос "Должен ли shared_ptr быть потокобезопасным. И если да, то какой memory_order использовать для счетчика ссылок?"

М>Дюже неприятно стало когда представил, что у меня такое на собеседовании спрашивают Гадость просто

А то! Я без сразу сдался, сказав что не надо трогать memory_order, если не помнишь наизусть соотвествующий раздел в cppreference. И даже если его прочитать, подумать, еще раз почитать, то все равно не надо трогать.

Здравствуйте, PM, Вы писали:

PM>>>Как бы вы ответили, например на вопрос "Должен ли shared_ptr быть потокобезопасным. И если да, то какой memory_order использовать для счетчика ссылок?"
Тё>>Нет, не должен.

PM>Скорее всего, после такого ответа будет итоговое "Спасибо, мы вам перезвоним."

Спасибо за информацию, назови контору пожалуйста, чтоб случайно к вам не отправил резюме.

Здравствуйте, PM, Вы писали:


PM> насколько я помню, такой баг реально исправляли не так давно в какой-то из реализаций.
Зачем тогда это давать на интервью? Если сам не понимаешь, так и грамотного кандидата срежешь- ведь сравнивать с бумажкой где-нибудь запятая не совпадет.

PM>Я без сразу сдался, сказав что не надо трогать memory_order, если не помнишь наизусть соотвествующий раздел в cppreference. И даже если его прочитать, подумать, еще раз почитать, то все равно не надо трогать.
Мда. Индусы в Бангалоре повыше квалификацией будут.

Здравствуйте, Тёмчик, Вы писали:

Тё>>Что это за C++ программисты такое пошли беспомощные?
PM>Так и в чем запинка? "Talk is cheap. Show me the code.” Покажите реализацию класса my_vector, проходящего тест выше. Публичный интерфейс пусть будет таким:

template<typename T>
class my_vector
{
public:
   vector(); // default initial state: size() == 0, capacity() == 0

   ??? size();
   ??? capacity();
   
   ??? operator[](??? index);

   ??? push_back(???);
};

PM>Вместо вопросов используйте подходящие типы. Дополнительные баллы если my_vector можно будет использовать в стиле C++11 т.е. так:

my_vector<int> vec{ 1, 2 3 };
int sum = 0;
for (auto&& x : vec) sum += x;
std::cout << sum;

Восстановил поскипаное. Скромность — это хорошо, но хотелось бы увидеть код от знатока C++ с уровнем 9/10

PM>>>>Как бы вы ответили, например на вопрос "Должен ли shared_ptr быть потокобезопасным. И если да, то какой memory_order использовать для счетчика ссылок?"
Тё>>>Нет, не должен.

PM>>Скорее всего, после такого ответа будет итоговое "Спасибо, мы вам перезвоним."

Тё>Спасибо за информацию, назови контору пожалуйста, чтоб случайно к вам не отправил резюме.

Я такое не спрашиваю, но можете вычеркивать TomTom, чтобы случайно не отправить туда резюме в 2016 году.

Здравствуйте, Тёмчик, Вы писали:

PM>> насколько я помню, такой баг реально исправляли не так давно в какой-то из реализаций.
Тё>Зачем тогда это давать на интервью? Если сам не понимаешь, так и грамотного кандидата срежешь- ведь сравнивать с бумажкой где-нибудь запятая не совпадет.

А зачем спрашивать реализацию std::reverse()? У каждого свои способы поддержания беседы

PM>>Я без сразу сдался, сказав что не надо трогать memory_order, если не помнишь наизусть соотвествующий раздел в cppreference. И даже если его прочитать, подумать, еще раз почитать, то все равно не надо трогать.
Тё>Мда. Индусы в Бангалоре повыше квалификацией будут.

Может быть некоторые и будут. Я нисколько не стесняюсь говорить, что cppreference.com — никогда не закрываемая вкладка у меня в браузере. Но хотелось бы увидеть ваш C++ код my_vector из соседней ветки попинайте пожалуйста резюме, чтобы было с чем сравнивать.

Здравствуйте, PM, Вы писали:

PM>Восстановил поскипаное. Скромность — это хорошо, но хотелось бы увидеть код от знатока C++ с уровнем 9/10
Ещё раз, для особо одаренных, 9/10 было в мою бытность C++ -м. В последний раз я прошёл тест на C++ IKM 99/100 в сентябре 2011г. Что ты докопался?

Здравствуйте, PM, Вы писали:

PM>А зачем спрашивать реализацию std::reverse()?
Я хз зачем спрашивать "реализацию std::reverse". Спрашивать "напиши разворот массива inplace на любом языке" я считаю правильно, чтоб отсеять таких, кто квадрат влепит.

PM>Может быть некоторые и будут. Я нисколько не стесняюсь говорить, что cppreference.com — никогда не закрываемая вкладка у меня в браузере.
Да и так видно, что изучение стандарта C++ для тебя- как изучение молитв для попа.

Здравствуйте, Тёмчик, Вы писали:

PM>>Восстановил поскипаное. Скромность — это хорошо, но хотелось бы увидеть код от знатока C++ с уровнем 9/10
Тё>Ещё раз, для особо одаренных, 9/10 было в мою бытность C++ -м. В последний раз я прошёл тест на C++ IKM 99/100 в сентябре 2011г. Что ты докопался?

То есть написать простейший динамический массив не можешь? "В динамическом массиве ничего нет сложного."

Так ты из беспомощных программистов которые для собеседования выучили только разворот строки. Ясно-понятно.

Здравствуйте, Тёмчик, Вы писали:

PM>>А зачем спрашивать реализацию std::reverse()?
Тё>Я хз зачем спрашивать "реализацию std::reverse". Спрашивать "напиши разворот массива inplace на любом языке" я считаю правильно, чтоб отсеять таких, кто квадрат влепит.

Ну пока что ты тут ни строчки кода не можешь привести.

PM>>Может быть некоторые и будут. Я нисколько не стесняюсь говорить, что cppreference.com — никогда не закрываемая вкладка у меня в браузере.
Тё>Да и так видно, что изучение стандарта C++ для тебя- как изучение молитв для попа.

Неа, я пользуюсь справочной информацией по стандартной библиотеке, в основном, чтобы посмотреть какая из 12 перегруженных std:string::find() подойдет. Разделы про язык мне для практической работы редко требуются, достаточно следить за развитием инструмента, которым пользуюсь каждый день.

А вот ты много лет подряд зачем-то упорно демонстрируешь полное непонимание в самых различных темах.

Здравствуйте, PM, Вы писали:

PM>Image: Stroustrup_cpp_knowledge_800x.png
Так это еще только теоретические знания стандарта, а если добавить необходимые в реальном мире знания систем сборки и управления зависимостями, то в среднем по больнице будет 3-4 будет в самом лучшем случае.

Здравствуйте, Skorodum, Вы писали:

PM>>Image: Stroustrup_cpp_knowledge_800x.png
S>Так это еще только теоретические знания стандарта, а если добавить необходимые в реальном мире знания систем сборки и управления зависимостями, то в среднем по больнице будет 3-4 будет в самом лучшем случае.

Согласен, но сборка, зависимости — это прикладные знания, которые в каждой компании свои, и со временем меняются. Кто сейчас вспомнит про scons, или как в MSBuild добавить флаг компилятора для одного файла в Release конфигурации.

Хотя, как предмет разговора, ответ вопрос "что вы использовали на предыдущем месте работы для сборки и управления зависимостями" вполне может продемонстрировать кругозор и опыт работы кандидата (и интервьюера, если у него тоже спросить "а вы что используете?")