Можно без шаблонов (если не считать таковым сам initializer_list) и читабельнее:
bool in(const int test_value, const std::initializer_list<int> values) {
for (const auto & value : values)
{
if (test_value == value)
{
return true;
}
}
return false;
}
// И где-то ниже
if (!in(errno, {EAGAIN, EWOULDBLOCK, EINTR, ENOSPC, ENOBUFS, ENOMEM}))
Хотя ещё лучше сделать in шаблоном и вместо int использовать T. Но в любом случае это не шаблоны на списке типов, где каждый новый список - это новая сгенерированная функция. А вообще в c++ появляется всё больше разного для замены макросов. И в шаблонах, и, например, constexpr/consteval для вычисления в compile time.
Когда они выпустили Gnome 3, он был очень глючный (начиная с того, что нормально не работал с несколькими мониторами), а очень стабильный Gnome 2 уже не поддерживался. Кроме того, Gnome 3 совсем не подходит любителям минимализма.
Очень надуманная причина. Gnome 2 был больше на MacOS ничуть не меньше, чем на Windows. В Gnome 3 тоже были панели, разве что запущенные приложения совместили с ярлыками и сделали крупнее (опять же как в MacOS).
Насколько я помню, тогда говорили, что Gnome 2 не подходит для планшетов, и нужна новая оболочка.
DLL hell — это всё же windows-специфичная проблема. Ад зависимостей может существовать и в linux'е, но для библиотек как правило всё хорошо. Да и разные мажорные версии утилит обычно могут быть установлены одновременно (тот же python).
По крайней мере в deb-пакете можно поставить зависимость, и эта библиотека не будет дублироваться для всех, кому она нужна.
На других системах тот же ICU системный так просто не заиспользуешь, и люди тянут свой, а это 30 МиБ только ресурсов (можно собрать урезанные для части локалей, но всё же), не считая мегабайтов самого кода. Потом curl (полмегабайта), openssl (более мегабайта), libpng и прочие аналогичные, zlib, OpenAL...
И ведь всё это не будешь самостоятельно писать (и лучше и не надо, без того же ICU почти наверняка локализация будет неправильной).
Если английский — не проблема, то у Introduction to algorithms недавно вышло 4 издание. На русский переведено пока только третье, но кардинальных отличий нет. Динамическое программирование там есть :)
Прошел первоначальное собеседование с HR (?), потом решал тестовые задачки, потом дали проект, который нужно было сдать за неделю. Сначала написал вопросы в духе "я буду при реализации использовать это, норм?". Ответа не получил, сделал за три полных дня. Потом на разборе моего решения мне сказали, что использовал не сильно распространённую технологию, и я должен всё ещё за неделю переписать на питоне. На моё возражение, что я задавал вопрос про это неделю назад последовало "да, я признаю, это ошибка, и потому даю вам ещё неделю, а не просто заваливаю". На то, что питон будет работать медленнее, чем моё решение, получил "зато он привычнее для заказчиков".
Решил, что я и без того потратил на них слишком много времени, ощущаю, что никакого уважительного отношения я тут не дождусь, и не хочу продолжать с ними общаться, написал, что решил прекратить с ними общаться, и потребовал, сославшись на GDPR, чтобы они удалили всю информацию обо мне. Не знаю, насколько честно выполнили, но аккаунт и профиль удалили.
Квалификация управленческих кадров часто не очень высокая, и из-за этого бывает много проблем. Например, микроменеджмент. Или неувольнение сотрудников, на которых все жалуются, потому что "ценный специалист" или "а как мы ему замену найдём". Или отсутствие похвалы при наличии большого числа критики. Или фокус не на результатах, а на том, сколько времени проведено в офисе. Таких примеров может быть много.
Это и создаёт таксичную культуру. А вот на то, что требуют работать, обычно не жалуются. Скорее, наоборот, проблемы возникают тогда, когда не увольняют тех, кто не работает, т.к. у работающих возникают вопросы.
Скорее придётся. Без нормальной автоматизации ракету сложно построить :)
И плюс постоянно возникает "так, почему у меня этого нет, ах, вон того не хватает, т.к. я теперь на вот это трачу", что довольно близко к программированию. Параллелизм, балансировка, кэш, дедлоки — всё на месте :)
У меня был опыт на прошлом месте работы, когда нам очень понравился кандидат — он знал всё лучше, чем мы, но оказалось, что вакансия висит "для повышения имиджа компании", реально никто не нужен. Обидно было и за человека (у него старая компания закрылась, и он искал срочно работу, т.к. семья и маленькие дети), и за себя (уже не первую неделю зря тратил время).
В России такой ответ приведёт к посту на каком-нибудь vc.ru, где его неплохо поднимут. Т.е. негативный пиар. Вот и получается, что в ситуации "не сработаемся" обходятся отсутствием обратной связи или общими словами.
Можно без шаблонов (если не считать таковым сам initializer_list) и читабельнее:
Хотя ещё лучше сделать in шаблоном и вместо int использовать T.
Но в любом случае это не шаблоны на списке типов, где каждый новый список - это новая сгенерированная функция.
А вообще в c++ появляется всё больше разного для замены макросов. И в шаблонах, и, например, constexpr/consteval для вычисления в compile time.
Есть 2gis.ru, её не хватает?
Построение маршрутов было, навигации не было.
Но ведь Metal появился раньше, чем Vulcan.
Формально один такой есть, но он обошёлся очень дорого, стоит дороже метро и до сих пор убыточен. Фактически, развлечение для туристов.
Но сейчас обычные поезда уже катаются на скорости 300+ км/ч, так что если убрать именно требование магнитной подушки, то вполне реальное допущение.
Когда они выпустили Gnome 3, он был очень глючный (начиная с того, что нормально не работал с несколькими мониторами), а очень стабильный Gnome 2 уже не поддерживался. Кроме того, Gnome 3 совсем не подходит любителям минимализма.
Очень надуманная причина. Gnome 2 был больше на MacOS ничуть не меньше, чем на Windows. В Gnome 3 тоже были панели, разве что запущенные приложения совместили с ярлыками и сделали крупнее (опять же как в MacOS).
Насколько я помню, тогда говорили, что Gnome 2 не подходит для планшетов, и нужна новая оболочка.
DLL hell — это всё же windows-специфичная проблема. Ад зависимостей может существовать и в linux'е, но для библиотек как правило всё хорошо. Да и разные мажорные версии утилит обычно могут быть установлены одновременно (тот же python).
Статическая линковка и LTO. Вот вторая проблема куда сложнее, для этого библиотеки надо специально для этого проектировать, а так мало кто делает.
По крайней мере в deb-пакете можно поставить зависимость, и эта библиотека не будет дублироваться для всех, кому она нужна.
На других системах тот же ICU системный так просто не заиспользуешь, и люди тянут свой, а это 30 МиБ только ресурсов (можно собрать урезанные для части локалей, но всё же), не считая мегабайтов самого кода. Потом curl (полмегабайта), openssl (более мегабайта), libpng и прочие аналогичные, zlib, OpenAL...
И ведь всё это не будешь самостоятельно писать (и лучше и не надо, без того же ICU почти наверняка локализация будет неправильной).
Если английский — не проблема, то у Introduction to algorithms недавно вышло 4 издание. На русский переведено пока только третье, но кардинальных отличий нет. Динамическое программирование там есть :)
Прошел первоначальное собеседование с HR (?), потом решал тестовые задачки, потом дали проект, который нужно было сдать за неделю. Сначала написал вопросы в духе "я буду при реализации использовать это, норм?". Ответа не получил, сделал за три полных дня. Потом на разборе моего решения мне сказали, что использовал не сильно распространённую технологию, и я должен всё ещё за неделю переписать на питоне. На моё возражение, что я задавал вопрос про это неделю назад последовало "да, я признаю, это ошибка, и потому даю вам ещё неделю, а не просто заваливаю". На то, что питон будет работать медленнее, чем моё решение, получил "зато он привычнее для заказчиков".
Решил, что я и без того потратил на них слишком много времени, ощущаю, что никакого уважительного отношения я тут не дождусь, и не хочу продолжать с ними общаться, написал, что решил прекратить с ними общаться, и потребовал, сославшись на GDPR, чтобы они удалили всю информацию обо мне. Не знаю, насколько честно выполнили, но аккаунт и профиль удалили.
Не рекомендую.
Идея хорошая, но не без проблем. Так, в rust уже год как не могут сделать сборку под последний NDK :(
Квалификация управленческих кадров часто не очень высокая, и из-за этого бывает много проблем. Например, микроменеджмент. Или неувольнение сотрудников, на которых все жалуются, потому что "ценный специалист" или "а как мы ему замену найдём". Или отсутствие похвалы при наличии большого числа критики. Или фокус не на результатах, а на том, сколько времени проведено в офисе. Таких примеров может быть много.
Это и создаёт таксичную культуру. А вот на то, что требуют работать, обычно не жалуются. Скорее, наоборот, проблемы возникают тогда, когда не увольняют тех, кто не работает, т.к. у работающих возникают вопросы.
Скорее придётся. Без нормальной автоматизации ракету сложно построить :)
И плюс постоянно возникает "так, почему у меня этого нет, ах, вон того не хватает, т.к. я теперь на вот это трачу", что довольно близко к программированию. Параллелизм, балансировка, кэш, дедлоки — всё на месте :)
И, к сожалению, встречал, что используют "нельзя сравнивать вещественные" как мантру, не разбираясь. И эта статья этому только способствует :)
Если числа не являются результатом вычислений, то сравнивать можно и нужно.
У меня был опыт на прошлом месте работы, когда нам очень понравился кандидат — он знал всё лучше, чем мы, но оказалось, что вакансия висит "для повышения имиджа компании", реально никто не нужен. Обидно было и за человека (у него старая компания закрылась, и он искал срочно работу, т.к. семья и маленькие дети), и за себя (уже не первую неделю зря тратил время).
В России такой ответ приведёт к посту на каком-нибудь vc.ru, где его неплохо поднимут. Т.е. негативный пиар. Вот и получается, что в ситуации "не сработаемся" обходятся отсутствием обратной связи или общими словами.
Может, речь о том, что поставленные игроком мины на игрока не реагируют?