С разморозкой, всё там можно, во всяком случае в Java. В ней ещё что хорошо, что есть те же Scala и Kotlin, которые хоть и другие языки, но вы остаетесь в той же экосистеме.
До прихода Яндекса и Убера вызывали такси по телефону, все те же функции, а то и больше, ибо общение шло с живым человеком и можно было договориться. Единственный существенный минус — в другом городе такси другие. Зато никогда не было такого, что оператор вам говорит, что машина едет/на месте, а таксист просто уезжает без вас, решив надурить систему. Была ответственность перед клиентом.
Аггрегаторы абсолютно неактуальны в пригородах и возможно маленьких городах. Там в итоге ждёшь полчаса факта, что машин нет и звонишь по старинке в местное.
Бомбилы на улице это отдельный пласт, живут параллельно, не было никакой эволюции из них в аггрегаторы, хотя некоторая часть туда ушла
Скорректирую вопрос. Если явно не поменить, что noexcept, и не использовать мув-конструктор по умолчанию, то всегда будет выбираться noexcept вариант (т.е. в случае вектора — медленное копирование)? Правило жесткое на уровне языка или есть маневр для компилятора, что он сам вычислит, что исключений не будет?
А не может ли кто-нибудь проявить на это свет? Я конечно, рад что можно сказать = default мув конструктору, но не всегда же они дефолтные.
У нас в проекте не принято расставлять noexcept, только если для самих-себя, т.е. в теле метода точно есть catch всего или ему вылетать неоткуда и использующему надо точно это знать. Но ситуация с вектором всегда напрягала.
Действительно ли noexcept делает что-то полезное? А если исключение все таки вылетит от туда?
Пардон, кусок кода был для обозначения конструкции. Однобуквенное название было лишь показатель того, что тут какой-то идентификатор.
auto errorCode=… лучше, чем int r=...
Все же, если там не int, а какой-то внятный enum (аля enum class в C++), то на мой взгляд ErrorCodeType error = process() лучше, чем auto errorCode = process(). Но тут уже кажется больше вкусовщина.
Не очень хочу спорить, потому что, к сожалению, имею только два осмысленных аргумента
1. усложняет чтение кода (скажем так, микроусложнение, но разве кто-то возразит, что его нет?).
2. со временем отупляет и уже перестаешь задумываться, а что там за тип под капотом, что иногда приводит к очень глупым ошибкам, которые можно бы было избежать подумав, правильный ли тип у переменной: самая простая ошибка — не влезло значение, потому что auto/var вывело int32, а мы потом умножили его несколько раз или вычли из unsigned и ушли за ноль.
Есть ещё третий момент, но он относится лишь к несовершенности IDE которыми довелось пользоваться. «Find usages» порой находит не всё (по разным причинам), а если везде указан тип, то достаточно бы было сделать grep по всем исходникам.
Вывод типа то есть, но это в любом случае надо позиционировать курсор на переменной и нажимать клавиши. Если таких переменных много, то вызывает больше неудобств, чем сложностей у человека указать явно тип, когда он писал код.
А дальше например идет foreach по этому контейнеры (то что это контейнер ясно из название функции и переменной, однако тут же вопрос, а вдруг там не линейный контейнер, а какой-то более сложный тип?)
auto и var — все-таки разные вещи, хотя и юзкейсы похожи.
Прошу меня извинить за непонимаю, что там придумали в Java, но кажется auto просто более фунциональней, потому что можно писать, например auto * или const auto &. А так же ещё auto можно засовывать в тип аргумента функции (шаблоны для бендых) и результирующее значение. Или же я изначально не прав?
Но что значит «запоминать тип»? Он неоднозначен или контекст теряется настолько, что даже имя не может помочь определиться?
Запомнить в прямом смысле). Загрузить в свой мозг объект, у которого тип такой-то и согласно типу, скорее всего можно провести вот такие-то операции, такие-то операции делать оптимально (с точки зрения быстродействия), такие-то нет. Если код сложный, то спрятанный тип загружает мозг сильней, чем если бы человек не поленился и написал тип.
Строгости кода это не мешает, зато DRY поддерживает.
Вам тоже отмечу, что против конструкции auto x = new Something ничего против не имею. Проблема возникает, когда зовут функцию, например process, в которой название отвечает за действие, а не за тип возвращаемого значения. auto r = process();
Что такое r? Какой-то результат. Не везде есть возможность и тип результата и действие уместить в одно название и неПолучитьОченьДлинноеНазваниеФункцииКотораяДелаетААвозващаетБ
На code-review, когда используется такой вывод типов, постоянно возникает вопрос, а подумал ли автор о типе переменной, он (тип) действительно не важен или человеку было просто лень и он «фигачил» строки одна за одной? Не знаю как в Java, а в C++ это довольно важный аспект при написании кода.
Плюсом ещё и изобретается аналог венгерской нотации (если совсем прищуриться), когда в название переменной засовывается информация о типе (в большей мере, чем нужно).
Нисколько не отрицаю мнения, что монстрообразные название типов действительно можно упрощать до автоматического вывода, но писать везде поголовно это опасно и нечитаемо (читаемо конечно, но времени больше тратится). В тех же плюсовых шаблонах иногда действительно лучше написать auto, а не пытаться понять, что там в итоге то должно быть.
Многие ещё говорят, что IDE же выводит тип, только вот у вас когда определенно 10 переменных и у всех auto, это все равно мука узнавать и запоминать, какой тип где, а через какое-то время повторять эту процедуру.
Жаль, что строгость кода почему-то не находит понимание.
Нет. Нельзя. Для наглядности возьмем всего двух влюбленных каждый в свои исследования «исследователя» и предложим им выделить N денег бюджета на разработки. Интересно, в какой из проектов каждый их них захочет вложить?
А почему нельзя делить «поровну» или на основе каких-то критериев? Как будто все люди звери, а в глазах у них $$$.
www.journaldev.com/2752/java-8-interface-changes-static-method-default-method
До прихода Яндекса и Убера вызывали такси по телефону, все те же функции, а то и больше, ибо общение шло с живым человеком и можно было договориться. Единственный существенный минус — в другом городе такси другие. Зато никогда не было такого, что оператор вам говорит, что машина едет/на месте, а таксист просто уезжает без вас, решив надурить систему. Была ответственность перед клиентом.
Аггрегаторы абсолютно неактуальны в пригородах и возможно маленьких городах. Там в итоге ждёшь полчаса факта, что машин нет и звонишь по старинке в местное.
Бомбилы на улице это отдельный пласт, живут параллельно, не было никакой эволюции из них в аггрегаторы, хотя некоторая часть туда ушла
www.youtube.com/watch?v=SShKf57XIKI
youtu.be/h-MunozvmW8?t=235
Скорректирую вопрос. Если явно не поменить, что noexcept, и не использовать мув-конструктор по умолчанию, то всегда будет выбираться noexcept вариант (т.е. в случае вектора — медленное копирование)? Правило жесткое на уровне языка или есть маневр для компилятора, что он сам вычислит, что исключений не будет?
А не может ли кто-нибудь проявить на это свет? Я конечно, рад что можно сказать = default мув конструктору, но не всегда же они дефолтные.
У нас в проекте не принято расставлять noexcept, только если для самих-себя, т.е. в теле метода точно есть catch всего или ему вылетать неоткуда и использующему надо точно это знать. Но ситуация с вектором всегда напрягала.
Действительно ли noexcept делает что-то полезное? А если исключение все таки вылетит от туда?
Пардон, кусок кода был для обозначения конструкции. Однобуквенное название было лишь показатель того, что тут какой-то идентификатор.
Все же, если там не int, а какой-то внятный enum (аля enum class в C++), то на мой взгляд ErrorCodeType error = process() лучше, чем auto errorCode = process(). Но тут уже кажется больше вкусовщина.
Не очень хочу спорить, потому что, к сожалению, имею только два осмысленных аргумента
1. усложняет чтение кода (скажем так, микроусложнение, но разве кто-то возразит, что его нет?).
2. со временем отупляет и уже перестаешь задумываться, а что там за тип под капотом, что иногда приводит к очень глупым ошибкам, которые можно бы было избежать подумав, правильный ли тип у переменной: самая простая ошибка — не влезло значение, потому что auto/var вывело int32, а мы потом умножили его несколько раз или вычли из unsigned и ушли за ноль.
Есть ещё третий момент, но он относится лишь к несовершенности IDE которыми довелось пользоваться. «Find usages» порой находит не всё (по разным причинам), а если везде указан тип, то достаточно бы было сделать grep по всем исходникам.
Прошу меня извинить за непонимаю, что там придумали в Java, но кажется auto просто более фунциональней, потому что можно писать, например auto * или const auto &. А так же ещё auto можно засовывать в тип аргумента функции (шаблоны для бендых) и результирующее значение. Или же я изначально не прав?
Запомнить в прямом смысле). Загрузить в свой мозг объект, у которого тип такой-то и согласно типу, скорее всего можно провести вот такие-то операции, такие-то операции делать оптимально (с точки зрения быстродействия), такие-то нет. Если код сложный, то спрятанный тип загружает мозг сильней, чем если бы человек не поленился и написал тип.
Вам тоже отмечу, что против конструкции auto x = new Something ничего против не имею. Проблема возникает, когда зовут функцию, например process, в которой название отвечает за действие, а не за тип возвращаемого значения.
auto r = process();Что такое r? Какой-то результат. Не везде есть возможность и тип результата и действие уместить в одно название и неПолучитьОченьДлинноеНазваниеФункцииКотораяДелаетААвозващаетБ
В случае, когда auto x = new Something, да, тавтология уходит, тут имелся в виду случай auto users = smth.getUsers()
Плюсом ещё и изобретается аналог венгерской нотации (если совсем прищуриться), когда в название переменной засовывается информация о типе (в большей мере, чем нужно).
Нисколько не отрицаю мнения, что монстрообразные название типов действительно можно упрощать до автоматического вывода, но писать везде поголовно это опасно и нечитаемо (читаемо конечно, но времени больше тратится). В тех же плюсовых шаблонах иногда действительно лучше написать auto, а не пытаться понять, что там в итоге то должно быть.
Многие ещё говорят, что IDE же выводит тип, только вот у вас когда определенно 10 переменных и у всех auto, это все равно мука узнавать и запоминать, какой тип где, а через какое-то время повторять эту процедуру.
Жаль, что строгость кода почему-то не находит понимание.
А почему нельзя делить «поровну» или на основе каких-то критериев? Как будто все люди звери, а в глазах у них $$$.