"Немного" это сколько?
Основные виды алгоритмов и структур?
Сложностные показатели?
Основные алгоритмы работы, в описательном виде?
Основные алгоритмы работы в деталях?
Доскональное знание всего вплоть до timsort, KD-tree и компании?
Увы, в С++ обработка ошибок через исключения меньше всего превращает код функции в бесконечные проверки, за которыми не видно логики. Коды возврата и коды состояния никуда не годятся, т.к. их очень легко проигнорировать. Either-style возвращаемые значения тоже не айс т.к. их во-первых нет в стандартной библиотеке, а во-вторых "раздувают" early return код — нет возможности сделать return из выражения.
Я бы предпочёл std::expected и немножко сахарку, чтобы это красиво чейнилось.
Не в курсе механик движка Source, но если он реализован на «порталах» — можно заранее просчитать, из каких комнат какие видны. И отправлять клиенту данные только тех комнат, которые «видны» из его текущей. На некоторых демках можно видеть, что воллхак срабатывает немного случайно.
Тогда смысл "не-нуллабельности" вообще нулевой получается — с учётом что 95% нынешнего кода не на Kotlin. Я при работе с внешним кодом не получаю от компилятора абсолютно никакой помощи, и точно так же могу схлопотать NPE почти в любой момент. Смысл был бы как раз заставить проверять инварианты на внешнем коде или прогонять какой-то статический чекер. А так синтаксис покрасивше, не более.
ИМХО тут автор как раз прав — сакральный смысл таких "манипуляций" стремится к нулю. В тот же Spring таких аннотаций не понаставишь. Логичнее как раз считать всё "чужеродное" максимально "небезопасным", если не указано иное.
Вообще странно. Год или полтора назад я читал, что в Kotlin специально решили считать все ссылки родом из Java — Nullable по умолчанию. И даже гоняли над JRE специальный верификатор, который составлял "карту аннотаций". Решили не заморачиваться, что ли?
Для меня например использование настроек для нескольких способов питания в одном плане контр-интуитивно. Было бы логичней КМК сделать каждый "план" просто пачкой настроек. И набор переключателей о событиям — на подключение шнурка питания, на работу от батареи, на определённый уровень заряда. Понятно, что какая система есть — такая есть.
Кстати, некоторые вендоры ноутбуков примерно так и делают — из специальной утилитки переключают планы. И можно настроить, в каком режиме питания какой план использовать.
Skype for Business — нет, спасибо. Пользуюсь сейчас по необходимости — корп стандарт. Так вот — даже обычный скайп, с учётом как его испоганил МС, в разы лучше
Редкое тормозилово
Неотключаемые и непереназначаемые клавиши. Ctrl+Enter стартует звонок, и это не поменять — никак
Дикая котовасия при включении — отключении микрофона
При включении демонстрации экрана задержка до 10 секунд
Скорее всего побуду Кэпом. Это называется Dispatch Table и напрямую в Асм вроде как не выражается. А выражается в джамп с вычисляемым адресом, перед которым стоит проверка что джамп не улетит в космос.
Я конечно не спец, но разве для такого не существует специальных решений, которые позволяют вместо 50-100 шнуров тянуть 1-2 толстых шины? Та же оптика будет слишком дорогой? Есть ведь предел для плотности такой укладки — когда потолок ДЦ грохнется под тяжестью кабелей.
Не автор, но отвечу. Как правило — поддержка железа. Xiaomi Mi 3. На вендорской прошивке датчик "приближения к уху" работает нормально, на цианогене — глючит безбожно. Решения найти не смог.
"Немного" это сколько?
Основные виды алгоритмов и структур?
Сложностные показатели?
Основные алгоритмы работы, в описательном виде?
Основные алгоритмы работы в деталях?
Доскональное знание всего вплоть до timsort, KD-tree и компании?
Увы, в С++ обработка ошибок через исключения меньше всего превращает код функции в бесконечные проверки, за которыми не видно логики. Коды возврата и коды состояния никуда не годятся, т.к. их очень легко проигнорировать. Either-style возвращаемые значения тоже не айс т.к. их во-первых нет в стандартной библиотеке, а во-вторых "раздувают" early return код — нет возможности сделать return из выражения.
Я бы предпочёл std::expected и немножко сахарку, чтобы это красиво чейнилось.
Тогда смысл "не-нуллабельности" вообще нулевой получается — с учётом что 95% нынешнего кода не на Kotlin. Я при работе с внешним кодом не получаю от компилятора абсолютно никакой помощи, и точно так же могу схлопотать NPE почти в любой момент. Смысл был бы как раз заставить проверять инварианты на внешнем коде или прогонять какой-то статический чекер. А так синтаксис покрасивше, не более.
ИМХО тут автор как раз прав — сакральный смысл таких "манипуляций" стремится к нулю. В тот же Spring таких аннотаций не понаставишь. Логичнее как раз считать всё "чужеродное" максимально "небезопасным", если не указано иное.
Вообще странно. Год или полтора назад я читал, что в Kotlin специально решили считать все ссылки родом из Java — Nullable по умолчанию. И даже гоняли над JRE специальный верификатор, который составлял "карту аннотаций". Решили не заморачиваться, что ли?
Ждём когда появится JEP на внедрение RAII, типов-смартпоинтеров и отделения ссылочности от типа :)
Это Вы С++ во всей его красе наверное не видели
Предложите что-нибудь на замену. К сожалению, 99% нынешних систем набиты костылями под завязку — даже перечислять не буду.
Для меня например использование настроек для нескольких способов питания в одном плане контр-интуитивно. Было бы логичней КМК сделать каждый "план" просто пачкой настроек. И набор переключателей о событиям — на подключение шнурка питания, на работу от батареи, на определённый уровень заряда. Понятно, что какая система есть — такая есть.
Кстати, некоторые вендоры ноутбуков примерно так и делают — из специальной утилитки переключают планы. И можно настроить, в каком режиме питания какой план использовать.
А подкиньте ссылочку пожалуйста
(del)
По поводу админов — у нас не собственный сервер, а облако МС.
Поделитесь косяками. Действительно интересно, без иронии.
Skype for Business — нет, спасибо. Пользуюсь сейчас по необходимости — корп стандарт. Так вот — даже обычный скайп, с учётом как его испоганил МС, в разы лучше
А Java умеет в метках диспатч-веток сложные неконстантные выражения?
А ещё гудбай статически просчитанный диспатч. Или надеяться на JIT.
Скорее всего побуду Кэпом. Это называется Dispatch Table и напрямую в Асм вроде как не выражается. А выражается в джамп с вычисляемым адресом, перед которым стоит проверка что джамп не улетит в космос.
Я конечно не спец, но разве для такого не существует специальных решений, которые позволяют вместо 50-100 шнуров тянуть 1-2 толстых шины? Та же оптика будет слишком дорогой? Есть ведь предел для плотности такой укладки — когда потолок ДЦ грохнется под тяжестью кабелей.
Не автор, но отвечу. Как правило — поддержка железа. Xiaomi Mi 3. На вендорской прошивке датчик "приближения к уху" работает нормально, на цианогене — глючит безбожно. Решения найти не смог.