Что такое гипергравитация? С антигравитацией понятно - у неё просто вектор обратный, а гипер это типа стягивания в некую сингулярность/соседнюю вселенную или как?
Огромное количество разработки ведётся по очень хиленько описанному ТЗ - "хочу фичу Х". Энтерпрайзы покрупнее, имеющие некоторый контролируемый цикл разработки имеют и достаточно понятный план разрабоки имеют также и аналитиков, которые формируют ТЗ для разработчика. Берусь утверждать, что в большинстве кампаний занимающиеся какой-то разработкой аналитиков не имеют по различным причинам: где-то количество экспериментов на единицу времени больше, где-то кампания слишком маленькая, чтобы держать ещё и аналитика пр. Поэтому разраб тут же становится сам себе аналитик и заодно и тестировщик со всеми вытекающими.
Вот тут не могу сказать. Говорят асинк на расте это максимум боли. Но примеры автора не затрагивали многопоточность/асинхронность в принципе, поэтому никого из них и не упомянул. Ну и оптимизировать эту часть обычно сложнее - внедрение lock-free, оптимизация планировщика, оптимизации пиннига памяти и вот это вот всё - вероятно есть окно, но принципиальных оптимизаций в эту часть добавить не выйдет на мой взгляд.
У вас не будет накладных расходов на интерфейсы и шланг половину ваших итераторов развернёт в автовекторизации. Учитывая что уходит ещё и GC, то там профит появится практически на ровном месте ещё просто из-за уменьшения потребления памяти. Часть имеющихся аллокаций конечно можно дополнительно потимизировать (типа тех же small object) но это уже зависит от того где боттлнеки. А так - flamegraph есть, criterion/hyperfine есть, встроенные бенчмарки есть - не знаю в каком месте можно будет столкнуться с проблемами c профилированием.
Как альтернативу ржавчины можно конечно попробовать Zig, но там инфраструктура ещё не выросла, но выглядит код очень похоже на Go, но не имеет его минусов.
Ровно то же самое что делают и сейчас - иметь некоторые тиры поддержки платформ. Условные триады (x86|arm)-(linux|windows)-blabla. Унифицировать бэкэнд для этих основных платформ не настолько большая проблема - gtk или qt как-то смогли же работать и под винды и под линукса и даже вроде под андроиды. Остальным остаётся брать графический контекст и рисовать компоненты и ввод самостоятельно - путь условного imgui/raylib.
в иксах, вейланде или условном фрейбуфере
бэкэнды обычно переключаются фичефлагами
разнообразие устройств и интерфейсов ввода
тоже меньшая из проблем. клавиатуры-джойстики обрабатываются достаточно легко ибо там наборы вводов обычно достаточно универсальные. VR/AR приблуды, микрофоны, камеры и иные контроллеры ествественно допиливаются отдельным напильником.
В стандартной библиотеке даже поддержки сети нет
высокоуровней поддержки нет, насколько я понимаю. необходимые примитивы вроде есть, но это не точно. Но в среднем это проблема из разряда "руки не дошли" на мой взгляд.
В таком случае обычно прикручивается какой-то TUI, но иксы к этому отношения не имеют ибо у GUI и TUI несколько разный набор проблем. Для эмбеда все держут обычно собственные домашние либы чтобы выводить на устройства визуального вывода. Под такое ни один известный язык не подстраивается, насколько мне известно.
То есть это даже не парковка?
Только слагаемые обычно складывают, а у вас в пояснении всё же множитель. А что есть t и почему они с r и c в аргументах функции?
Думал, что малые круги тоже будут прямыми, но они изоморфны окружностям на плоскости. Буду знать, спасибо.
И как сложить
c дедом?
JS в худшем случае просто бросит исключение про
undefinedт.к. его задача не ронять фронт никогда.во-во, удивляет желание людей заниматься подобным в обычных циклах.
Какой молодёжи если там демографический гэп из 90х?
Что такое гипергравитация? С антигравитацией понятно - у неё просто вектор обратный, а гипер это типа стягивания в некую сингулярность/соседнюю вселенную или как?
По определению - можно и даже иногда не одну и даже через одну и ту же точку не лежащей на данной прямой.
У вас в договоре указывается в какие периоды должна начисляться зп. Какая разница пришла она вам в 8.00 утра или к концу рабочего дня?
и? бухгалтер у работодателя будет зашиваться или что-то в этом духе? вас то это каким образом затрагивает?
Огромное количество разработки ведётся по очень хиленько описанному ТЗ - "хочу фичу Х". Энтерпрайзы покрупнее, имеющие некоторый контролируемый цикл разработки имеют и достаточно понятный план разрабоки имеют также и аналитиков, которые формируют ТЗ для разработчика. Берусь утверждать, что в большинстве кампаний занимающиеся какой-то разработкой аналитиков не имеют по различным причинам: где-то количество экспериментов на единицу времени больше, где-то кампания слишком маленькая, чтобы держать ещё и аналитика пр. Поэтому разраб тут же становится сам себе аналитик и заодно и тестировщик со всеми вытекающими.
Вот тут не могу сказать. Говорят асинк на расте это максимум боли. Но примеры автора не затрагивали многопоточность/асинхронность в принципе, поэтому никого из них и не упомянул. Ну и оптимизировать эту часть обычно сложнее - внедрение lock-free, оптимизация планировщика, оптимизации пиннига памяти и вот это вот всё - вероятно есть окно, но принципиальных оптимизаций в эту часть добавить не выйдет на мой взгляд.
Мне кажется как-то так ни на один пример в статье ссылок на годболт так и не получил.
У вас не будет накладных расходов на интерфейсы и шланг половину ваших итераторов развернёт в автовекторизации. Учитывая что уходит ещё и GC, то там профит появится практически на ровном месте ещё просто из-за уменьшения потребления памяти. Часть имеющихся аллокаций конечно можно дополнительно потимизировать (типа тех же small object) но это уже зависит от того где боттлнеки. А так - flamegraph есть, criterion/hyperfine есть, встроенные бенчмарки есть - не знаю в каком месте можно будет столкнуться с проблемами c профилированием.
Как альтернативу ржавчины можно конечно попробовать Zig, но там инфраструктура ещё не выросла, но выглядит код очень похоже на Go, но не имеет его минусов.
Ровно то же самое что делают и сейчас - иметь некоторые тиры поддержки платформ. Условные триады
(x86|arm)-(linux|windows)-blabla. Унифицировать бэкэнд для этих основных платформ не настолько большая проблема - gtk или qt как-то смогли же работать и под винды и под линукса и даже вроде под андроиды. Остальным остаётся брать графический контекст и рисовать компоненты и ввод самостоятельно - путь условного imgui/raylib.бэкэнды обычно переключаются фичефлагами
тоже меньшая из проблем. клавиатуры-джойстики обрабатываются достаточно легко ибо там наборы вводов обычно достаточно универсальные. VR/AR приблуды, микрофоны, камеры и иные контроллеры ествественно допиливаются отдельным напильником.
высокоуровней поддержки нет, насколько я понимаю. необходимые примитивы вроде есть, но это не точно. Но в среднем это проблема из разряда "руки не дошли" на мой взгляд.
В таком случае обычно прикручивается какой-то TUI, но иксы к этому отношения не имеют ибо у GUI и TUI несколько разный набор проблем. Для эмбеда все держут обычно собственные домашние либы чтобы выводить на устройства визуального вывода. Под такое ни один известный язык не подстраивается, насколько мне известно.
Примерно также как делают этой rayon, sdl и imgui - написать слой совместимости под общим API.
В вашем примере непонятно, что в принципе подаётся на вход и как это может взорвать парсер. Пока что выглядит как обычный линейный проход.
Вообще удивлён, что никаких окошек в стандартную библиотеку не завезли. jai вроде решал эту проблему едва ли не одной из первых.
Скорость света примерно пример миллиард км/ч, то есть грубо 2 тысячных от скорости света.
Чай не Regexp c lookahead чтобы взрываться.