Может причина в каких-то установаленных extensions? Понятно, что личный опыт ничего не доказывает, но использую firefox и под windows, и под linux. Проблем с утечками у меня нет.
Нет. Для опытного разработчика (не по стажу, а по реальному опыту) существенно не влияет.
Первые полчаса, максимум полдня стиль форматирования ещё заметен. Очень быстро наступает привыкание, и наступает привыкание. Есть намного более существенные факторы: дизайн проекта, хорошие имена идентификаторов (привет STL), декомпозиция кода, цикломатическая сложность, документация, поддержка навигации в IDE, удобство поиска по коду, наличие тестов и т.п. Форматирование плетётся в хвосте и ни на что существенно не влияет.
Везде где я работал подобные проблемы решались скучным запуском `bla-bla-bla-autoformat` перед коммитом с конфигом, хранящемся в VCS. Где-то даже были проверки стиля, не пропускающие неотформатированный по стандарту код.
И всё. Всем становилось пофигу: табы-или-пробельчики, на какой строчке ставить скобочку, сколькими пробельчиками отбивать скобочки/операторы, размер отступа, выравнивать или нет комментарии, как правильно именовать сущности (CamelCase vs sneak_case) + миллион других потенциальных тем для холивара.
По моему опыту у литкода очень расслабленные лимиты по времени. Зачастую (как и в вашем случае) можно взять заведомо неоптимальный алгоритм, и он пройдёт проверку.
Чтобы не быть голословным вот основная идея: Динамическое программирование
Предположим вы посчитали для заданного n следующие 6 чисел (количество eligible последовательностей длины n):
в последовательности 0 пропусков, в конце 0 опозданий
в последовательности 0 пропусков, в конце 1 опоздание
в последовательности 0 пропусков, в конце 2 опоздания
в последовательности 1 пропуск, в конце 0 опозданий
в последовательности 1 пропуск, в конце 1 опоздание
в последовательности 1 пропуск, в конце 2 опоздания
Зная эти 6 чисел для длины n легко посчитать эти 6 чисел для n+1 , причём они линейно выражаются через предыдущие. На каждом шаге достаточно хранить только эти 6 чисел.
Вторая идея - посмотрите как считается n-е число Фибоначчи за log(n). Здесь абсолютно тоже самое. Можно представить переход от n к n+1 как умножение на матрицу. Тогда вычисление n-го элемента сводится к возведение матрицы 6x6 в степень n, что делается за log(n) в константной памяти
-- Видите ли, доктор, чего я хочу -- я хочу, чтобы в тот день, когда
моя рукопись попадет в руки издателя, издатель, прочитав ее, поднялся бы с
места и сказал своим сотрудникам: "Господа, шапки долой!"
...
-- Целые вечера, целые недели бьешься над одним каким-нибудь словом...
а то и просто над согласованием.
Тут Гран остановился и схватил доктора за пуговицу пальто. Из его почти
беззубого рта слова вырывались с трудом.
-- Поймите меня, доктор. На худой конец, не так уж сложно сделать выбор
между "и" и "но". Уже много труднее отдать предпочтение "и" или "потом".
Трудности возрастают, когда речь идет о "потом" и "затем". Но, конечно,
самое трудное определить, надо ли вообще ставить "и" или не надо.
Кроме огромной головной боли MS от этого ничего не получит. Представляю, как функционал контекстного меню портировать под разнообразие DE Gnome/KDE/Xfce и т.п.
Всё что может рассинхронизироваться, рассинхронизируется с вероятностью 100%. И будет ещё хуже - решая несуществующую проблему шутников создадим другую. Робот проигнорирует реальный знак, поскольку у него либо будет старая карта, либа будет сбой связи, либо произойдёт сбой GPS, либо случится рассинхрон данных и кого-нибудь убъёт
Так и это не сложно. Но нигде не реализовано, потому что не стоит вложенных усилий
Сомневаюсь. Это не rocket science и несложно реализуемо, но никто не захотел тратить на это время
Может причина в каких-то установаленных extensions? Понятно, что личный опыт ничего не доказывает, но использую firefox и под windows, и под linux. Проблем с утечками у меня нет.
Интересно, это языки действительно без UB или не упоминающие о UB в своей спецификации?
Нет. Для опытного разработчика (не по стажу, а по реальному опыту) существенно не влияет.
Первые полчаса, максимум полдня стиль форматирования ещё заметен. Очень быстро наступает привыкание, и наступает привыкание. Есть намного более существенные факторы: дизайн проекта, хорошие имена идентификаторов (привет STL), декомпозиция кода, цикломатическая сложность, документация, поддержка навигации в IDE, удобство поиска по коду, наличие тестов и т.п. Форматирование плетётся в хвосте и ни на что существенно не влияет.
Нет, ну вы что угораете? Вы на полном серьёзе рассуждаете, что положение открывающей строки влияет на читабельность?
Везде где я работал подобные проблемы решались скучным запуском `bla-bla-bla-autoformat` перед коммитом с конфигом, хранящемся в VCS. Где-то даже были проверки стиля, не пропускающие неотформатированный по стандарту код.
И всё. Всем становилось пофигу: табы-или-пробельчики, на какой строчке ставить скобочку, сколькими пробельчиками отбивать скобочки/операторы, размер отступа, выравнивать или нет комментарии, как правильно именовать сущности (CamelCase vs sneak_case) + миллион других потенциальных тем для холивара.
В 2024 году кто-то ещё спорит про табы и пробелы. facepalm
<sarcasm on>Так статью на хабре про литкод вы не напишете</sarcasm on>
В остальном +1
По моему опыту у литкода очень расслабленные лимиты по времени. Зачастую (как и в вашем случае) можно взять заведомо неоптимальный алгоритм, и он пройдёт проверку.
Чтобы не быть голословным вот основная идея: Динамическое программирование
Предположим вы посчитали для заданного
nследующие 6 чисел (количествоeligibleпоследовательностей длиныn):в последовательности 0 пропусков, в конце 0 опозданий
в последовательности 0 пропусков, в конце 1 опоздание
в последовательности 0 пропусков, в конце 2 опоздания
в последовательности 1 пропуск, в конце 0 опозданий
в последовательности 1 пропуск, в конце 1 опоздание
в последовательности 1 пропуск, в конце 2 опоздания
Зная эти 6 чисел для длины
nлегко посчитать эти 6 чисел дляn+1, причём они линейно выражаются через предыдущие. На каждом шаге достаточно хранить только эти 6 чисел.Вторая идея - посмотрите как считается
n-е число Фибоначчи за log(n). Здесь абсолютно тоже самое. Можно представить переход отnкn+1как умножение на матрицу. Тогда вычислениеn-го элемента сводится к возведение матрицы6x6в степеньn, что делается заlog(n)в константной памятиВ вашем случае всё-таки дело в сложности алгоритма.
Ваша первая версия: O(n * log(n)) - сложность, O(n) - память
Ваш финальный вариант: O(n) - сложность, О(n) - память
Можно заметно лучше:
(hint: динамическое программирование): O(n) - сложность, O(1) - память
(hint: динамическое программирование + возведение в степень за log(n)): O(log(n)) - сложность, O(1) - память
Напомнило вот это
Альбер Камю. Чума
Кроме огромной головной боли MS от этого ничего не получит. Представляю, как функционал контекстного меню портировать под разнообразие DE Gnome/KDE/Xfce и т.п.
Переполнение для беззнаковых типов это не UB. Мне казалось что в Java нет unsigned типов. Что вы собрались чинить?
Как-то неудивительно. Хотя есть ещё викинги и лемминги, пришедшие откуда-то из скандинавских языков
В русском языке много слов, заканчивающиеся на "инг" - буллинг, тренинг, тюнинг, боулинг, дайвинг, пирсинг и т.п.
Немного занудства. Кнут утверждает, что LaTeX произносится как "латех". TeX - это τ (тау), ε (эпсилон) и χ (хи): https://en.wikipedia.org/wiki/TeX#Pronunciation_and_spelling
Всё что может рассинхронизироваться, рассинхронизируется с вероятностью 100%. И будет ещё хуже - решая несуществующую проблему шутников создадим другую. Робот проигнорирует реальный знак, поскольку у него либо будет старая карта, либа будет сбой связи, либо произойдёт сбой GPS, либо случится рассинхрон данных и кого-нибудь убъёт
Сразу вспомнил незабвенную 64-битная Windows — это очень просто