Это не одно и то же, если кто-то сам написал _ вместо err, значит сам специально не хотел обрабатывать ошибку, а вот если кто-то не обкладывает функции try.. catch, на все возможные исключения, то это потому, что всего не упомнишь, а язык и ide никак не подсказывает, где надо писать try..catch, а потом это особенность яп вырастает в проблему.
Hdr, sdr тут не причем, больше влияет олед, любой черный vs белый на олед - это очень большой контраст и тонкие настройки для электроники, при том, что есть не только белые пиксели, а так же внешние источники света.
Я же не на одну точку сотрю, двигаю глазами, картинка меняется, а глаза не могут быстро постраиваться под разный контраст. Ещё зрение моё не идедаьно, роговица - не иделаьная линза, есть небольшие неровности. И все эти факторы дают в моих глазах свечение белых букв на черном фоне на олед.
Когда на оледе ставлю большой контраст, где черный фон и белые буквы, то все белые буквы начинают сиять аурой, так что не, лучше всё в около серых цветах без сильного контраста, тогда будет похоже на цветной e-inc
первый тоже недооценивают, потому что он про расстояние около 1.5-2м и 50' дюймах, а может ещё больше. Причем так 2к достаточно, не микрошрифты же там рассматривать.
Мне все пункты понравились.
Ещё важно, чтобы окружающая подсветка была строго тускнее, чем монитор.
А я лет 10 исправляю ошибки кодеров, которые не понимают, как внутри работают новомодные, shared_ptr, корутины, темплейты и другие инструменты работы с памятью и с каждым разом это сложнее исправлять, ключевое слово здесь новомодные, когда явные изъяны архитектуры пытаются обойти всякими shared_ptr или пытаются оптимировать шаблонами, там где это не требуется и лучше было выбрать виртуальное наследование.
Было прекрасное время, когда люди знали что делают и думали об архитектуре, тогда даже goto в коде не вызывал ужасных неуловимых поломок. Если что-то можно сделать на Го, лучше это делать на Го, будет быстрее.
Да, можно прогнать линтер локально на проектах уровня хелловорлд+, но даже с 10-ти летним аосп это не выйдет и я не знаю, как там прогнать линтер отдельно. И зачем тратить время на поиски этой информации?
По-моему с++ скатился где-то на std::chrono и полностью превратися в Г при появлении корутин, все их пишут, куча реализаций, прироста с CSP почти никакого, проекты, в итоге, становятся неподдерживаемыми.
Ещё мне нравилось работать с базовыми типами, сейчас развели целый зоопарк, умножим, на шаблоны, которые раздувают объектный код, в итоге всё это работает и разрабатывается медленно.
Он ещё может сгореть, если отключить холодильник из розетки в момент максимального давления, а потом сразу включить. 1ф Асинхронник не сможет запуститься
У меня такой холодильник lg с такой платой обманкой, так вот проблемы пришли откуда не ждал. lg спроектировала холодильник под свой компрессор, который не дрожит. А теперь у меня в квартире холодильник с которым в одной комнате не поспишь, потому что в нем постоянно что-то дребезжит. Я уже пол холодильника виброй проклеил, но каждый раз находятся новые места. Но решение с платой считаю хорошим, если холодильник стоял бы не в спальном помещении.
В 5.15 был набор патчей который откатили в 5.17+, я про speculative page fault и был он только в андройд ядре. Если Гугл захочет, то могут также применить патч с частотами для андройда.
Да, тоже нравится тактильное ощущение "переламывания стеклянной палочки", на мембранной ножничной клавиатуре, просто елозишь пальцами по такой и чуть продавливаешь нужные кнопки. На длинноходных клавиатурах с болтающимися кнопками такого нет. И это всего-лишь dell kb-500 за 500р.
Ещё, с RAII в многопоточке конструктор всегда выполняется в одном потоке, а всякие методы Init() могут только добавить проблем. По моим наблюдениям такие Init() необходимы, чтобы использовать shared_from_this
Зубрежка слов ничего не даст, без закрепления в грамматике, мозг выкинет их как ненужный мусор. Я много лет учил английский по школьной программе, потом по университетской, всё время учил слова, всё было зря, пока не зашёл с грамматики.
Учить слова - это как в шахматах учить ходы дебютов, но не разбирать, зачем такой ход был сделать.
Из всей статьи я проверил на себе и окружении все тезисы, но работает только один: "Чаще, конечно, дело в ближайшем окружении...", то есть, если человек с детства разговорчивый и ему надо общаться, то он будет впитывать языки и социализироваться, иначе, будет впитывать косинусы с законами природы и т.п.. Когда к языку подходишь с точки зрения косинусов, то при построении предложения будет уходить много времени, всегда, даже через несколько лет, промежутки придется заполнять словами паразитами.
Когда код, например, мейна(любой клиентский код), будет использовать эти оба модуля, он запихнёт модуль А в конструктор модуля В через параметры и это правило будет работать, но я могу это представить только на С(на указателях функций) или Голанге(на утиной типизации), а на С++ и языках с чётким ООП не могу без дополнительных обёрток(которые точно испортят читаемость).
Пример бы посмотреть, а то статья без него какая-то неполная.
Да, ещё бы давали возможность телефон отвязать, или сделать так, что-бы смс не обходило пароль или totp
Это не одно и то же, если кто-то сам написал _ вместо err, значит сам специально не хотел обрабатывать ошибку, а вот если кто-то не обкладывает функции try.. catch, на все возможные исключения, то это потому, что всего не упомнишь, а язык и ide никак не подсказывает, где надо писать try..catch, а потом это особенность яп вырастает в проблему.
Те которые имеют противоположные признаки из списка, которых нет в Го:
-долгая компиляция(не поддерживаемый код)
-большой выбор операторов, перегрузка операторов, долго учить язык(нужен высокий уровень профессионализма)
-выключенный автоформаттер и линтер кода
-сложная система зависимостей или линковки
-выходной файл работает через интерпретатор(медленный код)
Убрать последний пункт и всё совпадет с Растом
Это проблема со зрением
Hdr, sdr тут не причем, больше влияет олед, любой черный vs белый на олед - это очень большой контраст и тонкие настройки для электроники, при том, что есть не только белые пиксели, а так же внешние источники света.
Я же не на одну точку сотрю, двигаю глазами, картинка меняется, а глаза не могут быстро постраиваться под разный контраст. Ещё зрение моё не идедаьно, роговица - не иделаьная линза, есть небольшие неровности. И все эти факторы дают в моих глазах свечение белых букв на черном фоне на олед.
Когда на оледе ставлю большой контраст, где черный фон и белые буквы, то все белые буквы начинают сиять аурой, так что не, лучше всё в около серых цветах без сильного контраста, тогда будет похоже на цветной e-inc
первый тоже недооценивают, потому что он про расстояние около 1.5-2м и 50' дюймах, а может ещё больше. Причем так 2к достаточно, не микрошрифты же там рассматривать.
Мне все пункты понравились.
Ещё важно, чтобы окружающая подсветка была строго тускнее, чем монитор.
А я лет 10 исправляю ошибки кодеров, которые не понимают, как внутри работают новомодные, shared_ptr, корутины, темплейты и другие инструменты работы с памятью и с каждым разом это сложнее исправлять, ключевое слово здесь новомодные, когда явные изъяны архитектуры пытаются обойти всякими shared_ptr или пытаются оптимировать шаблонами, там где это не требуется и лучше было выбрать виртуальное наследование.
Было прекрасное время, когда люди знали что делают и думали об архитектуре, тогда даже goto в коде не вызывал ужасных неуловимых поломок. Если что-то можно сделать на Го, лучше это делать на Го, будет быстрее.
Судя по лайкам, тут авторитет важнее, чем всё остальное
Когда в rust-e сделают компиляцию быструю и удобную как в Go, тогда он заменит Go и С++, а сейчас это вещь с кучей рекламных статей.
Тоже. Я не смог дальше двух тезисов прочитать, аллергия на бред началась.
Да, можно прогнать линтер локально на проектах уровня хелловорлд+, но даже с 10-ти летним аосп это не выйдет и я не знаю, как там прогнать линтер отдельно. И зачем тратить время на поиски этой информации?
По-моему с++ скатился где-то на std::chrono и полностью превратися в Г при появлении корутин, все их пишут, куча реализаций, прироста с CSP почти никакого, проекты, в итоге, становятся неподдерживаемыми.
Ещё мне нравилось работать с базовыми типами, сейчас развели целый зоопарк, умножим, на шаблоны, которые раздувают объектный код, в итоге всё это работает и разрабатывается медленно.
Он ещё может сгореть, если отключить холодильник из розетки в момент максимального давления, а потом сразу включить. 1ф Асинхронник не сможет запуститься
Так инвертор это хорошо.
У меня такой холодильник lg с такой платой обманкой, так вот проблемы пришли откуда не ждал. lg спроектировала холодильник под свой компрессор, который не дрожит. А теперь у меня в квартире холодильник с которым в одной комнате не поспишь, потому что в нем постоянно что-то дребезжит. Я уже пол холодильника виброй проклеил, но каждый раз находятся новые места. Но решение с платой считаю хорошим, если холодильник стоял бы не в спальном помещении.
В 5.15 был набор патчей который откатили в 5.17+, я про speculative page fault и был он только в андройд ядре. Если Гугл захочет, то могут также применить патч с частотами для андройда.
Да, тоже нравится тактильное ощущение "переламывания стеклянной палочки", на мембранной ножничной клавиатуре, просто елозишь пальцами по такой и чуть продавливаешь нужные кнопки. На длинноходных клавиатурах с болтающимися кнопками такого нет. И это всего-лишь dell kb-500 за 500р.
чтобы был разговорный английский, надо понять посыл статьи и изменить ваш подход к обучению.
А пока придираетесь к запятым, не видя сути, у вас будет только письменный английский ,чтение и понимание и ни шага вперед.
Придирщиков к запятым, опечаткам, очень много, продолжайте критику меня это не заденет.
Ещё, с RAII в многопоточке конструктор всегда выполняется в одном потоке, а всякие методы Init() могут только добавить проблем. По моим наблюдениям такие Init() необходимы, чтобы использовать shared_from_this
Зубрежка слов ничего не даст, без закрепления в грамматике, мозг выкинет их как ненужный мусор. Я много лет учил английский по школьной программе, потом по университетской, всё время учил слова, всё было зря, пока не зашёл с грамматики.
Учить слова - это как в шахматах учить ходы дебютов, но не разбирать, зачем такой ход был сделать.
Из всей статьи я проверил на себе и окружении все тезисы, но работает только один: "Чаще, конечно, дело в ближайшем окружении...", то есть, если человек с детства разговорчивый и ему надо общаться, то он будет впитывать языки и социализироваться, иначе, будет впитывать косинусы с законами природы и т.п.. Когда к языку подходишь с точки зрения косинусов, то при построении предложения будет уходить много времени, всегда, даже через несколько лет, промежутки придется заполнять словами паразитами.
Когда код, например, мейна(любой клиентский код), будет использовать эти оба модуля, он запихнёт модуль А в конструктор модуля В через параметры и это правило будет работать, но я могу это представить только на С(на указателях функций) или Голанге(на утиной типизации), а на С++ и языках с чётким ООП не могу без дополнительных обёрток(которые точно испортят читаемость).
Пример бы посмотреть, а то статья без него какая-то неполная.