Сообщение Re[18]: попинайте пожалуйста резюме от 28.05.2021 3:37
Изменено 28.05.2021 3:57 Артём
Re[18]: попинайте пожалуйста резюме
Здравствуйте, PM, Вы писали:
PM>>>>>если хотите завалить С++ программиста на собеседовании, попросите его реализовать std::vector или std::shared_ptr + weak_ptr. Если кандидат справился с заданием, то перед вами STL, или вы просто знаете С++ хуже кандидата.
Тё>>Я был лучшего мнения о C++ программистах
PM>Как бы вы оценили свои знания C++ по 10-бальной шкале, где 0 — не знаю совсем?
В бытность мою плюсником 9/10.
S>>>>amadeus в Boston просит на доске реализовать vector
PM>>>У вас получилось? Оно поддерживает custom allocator? является exception safe? Умеет хранить move-only noexcept значения?
Тё>>Если программист C++ понимает эти вещи- он их учтёт в реализации вектора. А если "программист C++" ака говнокодер вульгарис, кто утверждает, что на жава только опердни в индийском аутсорсе, что ж
PM>Если кандидат начнет писать на собеседовании вектор с учетом всех этих вещей, то ему и дня может не хватить. Вообще, есть утверждение, что невозможно реализовать std::vector, оставаясь в рамках стандарта C++, т.к. некторые вещи можно сделать только компиляторо-/платформо- зависимым способом.
Что это за C++ программисты такое пошли беспомощные?
PM>Там уже в конструкторе cowinotrid есть OOM, и ошибка которую никто не заметил. Про удвоение емкости при нехватке места нет никаких гарантий, емкость может увеличиваться любым способом.
Ну извините, вы вывалили кучку жидкого кала, и предлагаете найти в нем все ошибки? Насчёт удвоения capacity- это обычная практика, для улучшения amortized complexity.
PM>Но для вас же это не сложнее переворота строки и вы сможете реализовать минимальный аналог std::vector который пройдет такой тест?
PM>
В чём запинка? Если не вдаваться в move semantics, которую я уже не застал- вызвать копирующие конструкторы (через оператор "=". Возможно, какой-нить std::move нагуглить. Важно же найти сообразительность, а не зазубренность API
PM>Как бы вы ответили, например на вопрос "Должен ли shared_ptr быть потокобезопасным. И если да, то какой memory_order использовать для счетчика ссылок?"
Нет, не должен.
PM>>>>>если хотите завалить С++ программиста на собеседовании, попросите его реализовать std::vector или std::shared_ptr + weak_ptr. Если кандидат справился с заданием, то перед вами STL, или вы просто знаете С++ хуже кандидата.
Тё>>Я был лучшего мнения о C++ программистах
PM>Как бы вы оценили свои знания C++ по 10-бальной шкале, где 0 — не знаю совсем?
В бытность мою плюсником 9/10.
S>>>>amadeus в Boston просит на доске реализовать vector
PM>>>У вас получилось? Оно поддерживает custom allocator? является exception safe? Умеет хранить move-only noexcept значения?
Тё>>Если программист C++ понимает эти вещи- он их учтёт в реализации вектора. А если "программист C++" ака говнокодер вульгарис, кто утверждает, что на жава только опердни в индийском аутсорсе, что ж
PM>Если кандидат начнет писать на собеседовании вектор с учетом всех этих вещей, то ему и дня может не хватить. Вообще, есть утверждение, что невозможно реализовать std::vector, оставаясь в рамках стандарта C++, т.к. некторые вещи можно сделать только компиляторо-/платформо- зависимым способом.
Что это за C++ программисты такое пошли беспомощные?
PM>Там уже в конструкторе cowinotrid есть OOM, и ошибка которую никто не заметил. Про удвоение емкости при нехватке места нет никаких гарантий, емкость может увеличиваться любым способом.
Ну извините, вы вывалили кучку жидкого кала, и предлагаете найти в нем все ошибки? Насчёт удвоения capacity- это обычная практика, для улучшения amortized complexity.
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
PM>Как бы вы ответили, например на вопрос "Должен ли shared_ptr быть потокобезопасным. И если да, то какой memory_order использовать для счетчика ссылок?"
Нет, не должен.
Re[18]: попинайте пожалуйста резюме
Здравствуйте, PM, Вы писали:
PM>>>>>если хотите завалить С++ программиста на собеседовании, попросите его реализовать std::vector или std::shared_ptr + weak_ptr. Если кандидат справился с заданием, то перед вами STL, или вы просто знаете С++ хуже кандидата.
Тё>>Я был лучшего мнения о C++ программистах
PM>Как бы вы оценили свои знания C++ по 10-бальной шкале, где 0 — не знаю совсем?
В бытность мою плюсником 9/10.
S>>>>amadeus в Boston просит на доске реализовать vector
PM>>>У вас получилось? Оно поддерживает custom allocator? является exception safe? Умеет хранить move-only noexcept значения?
Тё>>Если программист C++ понимает эти вещи- он их учтёт в реализации вектора. А если "программист C++" ака говнокодер вульгарис, кто утверждает, что на жава только опердни в индийском аутсорсе, что ж
PM>Если кандидат начнет писать на собеседовании вектор с учетом всех этих вещей, то ему и дня может не хватить. Вообще, есть утверждение, что невозможно реализовать std::vector, оставаясь в рамках стандарта C++, т.к. некторые вещи можно сделать только компиляторо-/платформо- зависимым способом.
Что это за C++ программисты такое пошли беспомощные?
PM>Там уже в конструкторе cowinotrid есть OOM, и ошибка которую никто не заметил. Про удвоение емкости при нехватке места нет никаких гарантий, емкость может увеличиваться любым способом.
Ну извините, вы вывалили кучку жидкого кала, и предлагаете найти в нем все ошибки? Насчёт удвоения capacity- это обычная практика, для улучшения amortized complexity.
PM>Но для вас же это не сложнее переворота строки и вы сможете реализовать минимальный аналог std::vector который пройдет такой тест?
PM>
В чём запинка? Если не вдаваться в move semantics, которую я уже не застал- вызвать копирующие конструкторы (через оператор "=". Возможно, какой-нить std::move нагуглить. Важно же найти сообразительность, а не зазубренность API
PM>Как бы вы ответили, например на вопрос "Должен ли shared_ptr быть потокобезопасным. И если да, то какой memory_order использовать для счетчика ссылок?"
Нет, не должен.
Что вы понимаете под memory order? Вы хотели сказать, memory barrier? В общем случае, не нужно делать потокобезопасным, по причине что memory barrier небесплатен.
PM>>>>>если хотите завалить С++ программиста на собеседовании, попросите его реализовать std::vector или std::shared_ptr + weak_ptr. Если кандидат справился с заданием, то перед вами STL, или вы просто знаете С++ хуже кандидата.
Тё>>Я был лучшего мнения о C++ программистах
PM>Как бы вы оценили свои знания C++ по 10-бальной шкале, где 0 — не знаю совсем?
В бытность мою плюсником 9/10.
S>>>>amadeus в Boston просит на доске реализовать vector
PM>>>У вас получилось? Оно поддерживает custom allocator? является exception safe? Умеет хранить move-only noexcept значения?
Тё>>Если программист C++ понимает эти вещи- он их учтёт в реализации вектора. А если "программист C++" ака говнокодер вульгарис, кто утверждает, что на жава только опердни в индийском аутсорсе, что ж
PM>Если кандидат начнет писать на собеседовании вектор с учетом всех этих вещей, то ему и дня может не хватить. Вообще, есть утверждение, что невозможно реализовать std::vector, оставаясь в рамках стандарта C++, т.к. некторые вещи можно сделать только компиляторо-/платформо- зависимым способом.
Что это за C++ программисты такое пошли беспомощные?
PM>Там уже в конструкторе cowinotrid есть OOM, и ошибка которую никто не заметил. Про удвоение емкости при нехватке места нет никаких гарантий, емкость может увеличиваться любым способом.
Ну извините, вы вывалили кучку жидкого кала, и предлагаете найти в нем все ошибки? Насчёт удвоения capacity- это обычная практика, для улучшения amortized complexity.
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
PM>Как бы вы ответили, например на вопрос "Должен ли shared_ptr быть потокобезопасным. И если да, то какой memory_order использовать для счетчика ссылок?"
Нет, не должен.
Что вы понимаете под memory order? Вы хотели сказать, memory barrier? В общем случае, не нужно делать потокобезопасным, по причине что memory barrier небесплатен.