Был бы на уровне компиляции запрет на использование объекта после move - у меня и вопросов бы не было. А так добавили еще один инструмент, который делает код плохо поддерживаемым.
Какую проблему вы видите с указателями? Мув почти никогда не беспатный. Да, он дешевый, ну так и копирование shared указателя дешевое.
Это не буквально тоже самое. Как много вы видели конструкторов объектов, которые изменяют состояния входящих объектов? Ожидаете ли вы такого поведения от конструктора? Ожидаете ли вы в принципе, что конструктор что-то меняет во внешних переменных? Часто ли вы используете функции, которые меняют состояние переменных непредсказуемо? То есть вы даже посмотрев на код функции не можете сказать, в каком состоянии будет переменная. И вся эта мув семантика без проблем заменяется умными указателями. С абсолютно понятным и предсказуемым поведением. Причем при работе с указателями любой класс будет себя вести одинаково. И вот этого "вы сами написали кривой класс" не имеет значения, потому что класс в перемещении указателя не фигурирует. Мув семантика - это костыль, которые прикрутили, потому что народ боится указателей. Но указатели есть и будут важной частью плюсов. Не любишь указатели - просто выбери другой язык. Не надо из-за этого костыли прикручивать.
Как же мне не нравится std::move... Мы буквально не можем использовать переменную, которая после передачи в функцию может перестать быть инициализированной. То есть у нас код, в котором переменная которая нормально работает(и мы, может быть, даже в начале проверили что она ввлидная) в один прекрасный момент достаточно прозрачно и незаметно становится невалидной. Простите, но я лучше буду пользоваться указателями.
Ну к слову, в конкретно этом интервью никаких проблем не было. Интервьюверы адекватные и мои достаточно частые "я это не знаю/не помню" как приговор не восприняли и оффер я получил.
Не все хорошие техлиды - хорошие интервьюверы. Все истории выглядят так, что техлид отбросил кандидатов по неадекватным причинам.
Я и сам таким был. Помню как гневался что приходится работать с людьми, которые не понимают почему float width = 1 / screenWidthPixelsCount; дает ноль. Я бы таких на работу не взял!!! Хорошо что я лидил, а не брал на работу. Потому что люди приходили, спрашивали почему не работает, получали ответ, исправляли и дальше просто делали свою работу.
Проблема вопросов по базе в том, что они могут не иметь отношения к реальным юз кейсам. Не так давно собеседовался в компанию как Unreal Engine плюсовик. Обсуждали ромбовидное наследование что это, как правильно наследоваться и что будет в разных вариантах наследования. Всё что я мог сказать: "Да, я конечно читал про проблемы ромбовидного наследования. Лет 10 назад. Потому что на практике мы его нигде и никогда не используем из-за того что это проблемная штука, которой нужно избегать."
И вот получается - это база. И это база, которую я не знаю(вернее не помню, но это одно и тоже). Давайте меня браковать за это?
А куда уран девать то тогда? Его тысячи тонн. Особенно если использовать реакторы полного цикла. АЭС - отличный способ утилизации радиоактивной руды с пользой для человечества. Но есть проблема... Все передовые атомные технологии принадлежат одной нерукопожатной стране. Её бы, конечно, развалить и технологии забрать. Но пока не получается.
Повторю свой комментарий из удаленной статьи: Денис Попов - нормальный школьник, сделавший на уровне своей компетенции школьный проект и получивший спорное освещение в СМИ. Автор же AsmX - неадекват. Не надо их сравнивать.
Про некомпетентность рассуждает человек, который не знал что стандартные типы после мува по стандарту имеют Undefined State.
Был бы на уровне компиляции запрет на использование объекта после move - у меня и вопросов бы не было. А так добавили еще один инструмент, который делает код плохо поддерживаемым.
Какую проблему вы видите с указателями? Мув почти никогда не беспатный. Да, он дешевый, ну так и копирование shared указателя дешевое.
Это не буквально тоже самое. Как много вы видели конструкторов объектов, которые изменяют состояния входящих объектов? Ожидаете ли вы такого поведения от конструктора? Ожидаете ли вы в принципе, что конструктор что-то меняет во внешних переменных?
Часто ли вы используете функции, которые меняют состояние переменных непредсказуемо? То есть вы даже посмотрев на код функции не можете сказать, в каком состоянии будет переменная.
И вся эта мув семантика без проблем заменяется умными указателями. С абсолютно понятным и предсказуемым поведением. Причем при работе с указателями любой класс будет себя вести одинаково. И вот этого "вы сами написали кривой класс" не имеет значения, потому что класс в перемещении указателя не фигурирует.
Мув семантика - это костыль, которые прикрутили, потому что народ боится указателей. Но указатели есть и будут важной частью плюсов. Не любишь указатели - просто выбери другой язык. Не надо из-за этого костыли прикручивать.
Как же мне не нравится std::move...
Мы буквально не можем использовать переменную, которая после передачи в функцию может перестать быть инициализированной.
То есть у нас код, в котором переменная которая нормально работает(и мы, может быть, даже в начале проверили что она ввлидная) в один прекрасный момент достаточно прозрачно и незаметно становится невалидной.
Простите, но я лучше буду пользоваться указателями.
Так то оно да. Но у них следующий уровень: вести войны руками чужих аборигенов, а не своих.
А она изменилась?
Хотя о чем это я. Конечно изменилась. Они научились вести войны чужими руками.
1.0f иначе там double. Ответ даст правильный. Но для производительности похуже. Да и варнинг будет.
Ну к слову, в конкретно этом интервью никаких проблем не было. Интервьюверы адекватные и мои достаточно частые "я это не знаю/не помню" как приговор не восприняли и оффер я получил.
Не все хорошие техлиды - хорошие интервьюверы.
Все истории выглядят так, что техлид отбросил кандидатов по неадекватным причинам.
Я и сам таким был. Помню как гневался что приходится работать с людьми, которые не понимают почему float width = 1 / screenWidthPixelsCount; дает ноль.
Я бы таких на работу не взял!!!
Хорошо что я лидил, а не брал на работу. Потому что люди приходили, спрашивали почему не работает, получали ответ, исправляли и дальше просто делали свою работу.
Проблема вопросов по базе в том, что они могут не иметь отношения к реальным юз кейсам.
Не так давно собеседовался в компанию как Unreal Engine плюсовик. Обсуждали ромбовидное наследование что это, как правильно наследоваться и что будет в разных вариантах наследования. Всё что я мог сказать: "Да, я конечно читал про проблемы ромбовидного наследования. Лет 10 назад. Потому что на практике мы его нигде и никогда не используем из-за того что это проблемная штука, которой нужно избегать."
И вот получается - это база. И это база, которую я не знаю(вернее не помню, но это одно и тоже). Давайте меня браковать за это?
Ну если вы меня спрашиваете, то я не знаю. Но надеюсь, что треснут.
В смысле "будут"... БН-800 для вас шутка? Год назад впервые МОКС топливо загрузили.
Так уже построили. Вроде в этом году закончили цикл испытаний.
Другое дело снаряды и броня из обедненного урана. Самые экологичные. Не то что эти ваши АЭС.
А куда уран девать то тогда? Его тысячи тонн. Особенно если использовать реакторы полного цикла. АЭС - отличный способ утилизации радиоактивной руды с пользой для человечества.
Но есть проблема... Все передовые атомные технологии принадлежат одной нерукопожатной стране. Её бы, конечно, развалить и технологии забрать. Но пока не получается.
you.com?
Повторю свой комментарий из удаленной статьи:
Денис Попов - нормальный школьник, сделавший на уровне своей компетенции школьный проект и получивший спорное освещение в СМИ. Автор же AsmX - неадекват. Не надо их сравнивать.
Он свою первую статью благополучно грохнул.
Одно не понятно:
Было же сразу видно что это скам. Зачем автор тратил своё время, чтобы в этом разобраться?
В природе и математики нет.
Системы счисления вполне себе "физичная" вещь и многие свойства интересные вылезают именно применимо к системам счисления.