| 1.1, Аноним (1), 22:44, 09/10/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Ох, эта libcue такая кривая дрянь, вы таки не поверите. По-моему даже если файл не заканчивается пустой строкой сегфолтится. Использовать её для автоматического разбора файлов несколько опрометчиво (хотя вполне ожидаемо для гномеров).
| | |
| |
| 2.6, коньюктивит (?), 23:31, 09/10/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
О, да. Я помню как долго с этим бился. Бывало, отредактируешь cue sheet в винде из foobar как тебе нужно и всё зашибись. Но потом в линуксе опа! и этот куй не читается? Я дооолго не мог понять в чём дело. Кодировка? Нет. Тогда почему? Голову сломал. И только как-то невзначай до меня вдруг дошло, что я при редактировании всегда убираю пустую строку в конце. Ну а нахер она нужна? Некрасиво же. А вот невменяемому линуксу оказывается она жизненно необходима! И смех и грех.
| | |
| |
| 3.21, Аноним (21), 01:27, 10/10/2023 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> при редактировании всегда убираю пустую строку в конце. Ну а нахер она нужна?
Текстовый файл -- это последовательность строк. Строка -- это последовательность символов, завершающихся символом "\n". Держи формальное определение:
TEXT := LINE*
LINE := [^\n]* "\n"
Когда убираешь пустую строку в конце непустого файла, файл перестает быть текстовым и становится... бинарным. По определению.
| | |
| |
| |
| 5.25, Аноним (25), 01:43, 10/10/2023 [^] [^^] [^^^] [ответить]
| +4 +/– |
> я при редактировании всегда убираю пустую строку в конце
> пофиг. Мне тоже.
Я специально удаляю конец последней строки в файле, потому что мне пофик.
| | |
|
| 4.23, Аноним (25), 01:40, 10/10/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Можно ещё сказать, что когда убираешь символ конца строки после последней строки, последняя строка становится бесКОНЕЧной, и падение библиотеки при её парсинге неудивительно (кроме случаев, когда у пользователя бесконечное количество оперативной памяти).
| | |
| |
| 5.41, Аноним (68), 06:58, 10/10/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Можно ещё сказать, что когда убираешь символ конца строки после последней строки,
> последняя строка становится бесКОНЕЧной
Бесконечных вещей всего две: Вселенная и человеческая глупость.
| | |
| |
| 6.43, ryoken (ok), 08:06, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
 >>Бесконечных вещей всего две: Вселенная
Есть теория, согласно которой Вселенная конечна, но постоянно расширяется, так что до края не доберёшься.
| | |
|
|
| 4.27, Аноним (27), 02:56, 10/10/2023 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> файл перестает быть текстовым и становится... бинарным
Странно, я всегда думал что файл - это просто набор байт, который можно интерпретировать как угодно. Это какой-то очередной бессмысленный атавизм из 70-х, вроде символа возврата каретки или символа звона телетайпа (bell character). Многие повторяют, и лупят других чтобы тоже повторяли, хотя уже не помнят почему и зачем, как в эксперименте с обезьянами и поливальным шлангом.
| | |
| |
| 5.44, Аноним (44), 08:55, 10/10/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
А ещё в конце файла обязательно должен быть байт 0x1A!!! (в Windows кстати copy file1+file2 filenew вроде до сих пор его добавляет)
| | |
|
| 4.28, Аноним (28), 03:12, 10/10/2023 [^] [^^] [^^^] [ответить]
| +5 +/– |
\n — это не часть строки. Это разделитель строк. Зачем он нужен в конце файла — решительно непонтяно.
Причём он разный бывает — у кого \n, у кого \r\n, а у кого и вовсе \r.
| | |
| |
| 5.40, Аноним (68), 06:55, 10/10/2023 [^] [^^] [^^^] [ответить]
| +3 +/– |
Потому что при склейке файлов утилитой cat уютный мирок кекспертов по строкам начинает сыпаться.
| | |
|
| 4.39, Аноним (68), 06:53, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Держи формальное определение:
> TEXT := LINE*
> LINE := [^\n]* "\n"
А теперь предоставь ссылку на компетентный источник.
| | |
| |
| |
| 6.67, Аноним (68), 16:43, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html:
>> Text File
>>
>> A file that contains characters organized into zero or more lines.
Although POSIX.1-2017 does not distinguish between text files and binary files (see the ISO C standard), many utilities only produce predictable or meaningful output when operating on text files. The standard utilities that have such restrictions always specify "text files" in their STDIN or INPUT FILES sections.
>> Line
>>
>> A sequence of zero or more non- <newline> characters plus a terminating <newline> character.
The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the <newline> character.
Упс. Какой же пункт прав?
| | |
| |
| 7.70, MaleDog (?), 18:32, 10/10/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
И в чем противоречие? При чтении строки выделяется буфер, длинна строки включая '\n' не должна превышать размер буфера. LINE_MAX обычно 2048 байт. Дальше программист сам решает что делать с огрызком меньше 2048, но не закончившимся '\n'.
Можно выбросить, можно на ской страх и риск добавить '\n'. А можно выбросить и весь файл, как не соответствующий стандарту или поврежденный. Ведь такой файл вполне может получиться при аварийном обрыве записи, например при записи вырубили питание или прибили процесс, или при передаче сеть отвалилась.
| | |
| |
| 8.89, Аноним (68), 16:56, 11/10/2023 [^] [^^] [^^^] [ответить] | +/– | С этим Какому такому стандарту и при чём тут вообще POSIX File format Cuesheet... большой текст свёрнут, показать | | |
| |
| 9.95, MaleDog (?), 21:41, 28/10/2023 [^] [^^] [^^^] [ответить] | +/– | При том, что когда-то давно, когда безупречная работа компьютеров и сетей не гар... большой текст свёрнут, показать | | |
|
|
|
| 6.72, Аноним (28), 20:24, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> POSIX
Ну то есть для юниксов, то есть для линуксов. Алё! За их пределами жизнь есть!
Про {LINE_MAX} особенно понравилось. Это-то вообще из какого стандарта?
| | |
| |
| 7.77, MaleDog (?), 00:45, 11/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
POSIX. И те кто его соблюдает не будут испытывать проблем с парсингом текстовых файлов совместимых с POSIX. Вне зависимости от того какую систему они используют. Linux, unix, bsd и т.п. даже windows и macos кмк. Остальные... ну можно теоретически ездить и по левой стороне дороги, и кто-то из встречных даже будет уворачиваться, но рано или поздно возможно столкновение с камазом.
Кстати, современные приложения пытаются как могут и даже подстраиваются к строкам гораздо длиннее LINE_MAX, но последнюю строку без терминатора в большинстве случаев игнорируют.
| | |
| |
| 8.78, MaleDog (?), 01:01, 11/10/2023 [^] [^^] [^^^] [ответить] | +1 +/– | Может за пределами linux жизнь и есть, но весьма печальная У каждого в доме ест... текст свёрнут, показать | | |
|
| 7.90, Аноним (68), 17:20, 11/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
>> POSIX
> Ну то есть для юниксов, то есть для линуксов. Алё! За их
> пределами жизнь есть!
За их пределами и возник этот Cuesheet:
The cue sheet format was invented by Jeff Arnold of GoldenHawk Technology for use with his DAO (Disc At Once) and CDRWIN applications. The format has since been adopted as the de facto standard, and is used by various other applications, including the audio player foobar2000. The official cue sheet specification is widely accepted to be Appendix A of the CDRWIN User's Guide.
> Про {LINE_MAX} особенно понравилось. Это-то вообще из какого стандарта?
Ну что не ясно, всякая программа должна вызвать баш и выполнить getconf LINE_MAX, а потом работать по стандарту.)))
| | |
|
|
|
|
|
|
| 1.4, Карлос Сношайтилис (ok), 23:21, 09/10/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
 Господи, это же просто тестовый файл! Как можно написать кривой код, его читающий?!
Надо проверить как они строки читают, нет ли там кастомной либы для преобразования строк. Это в стиле сишников – изобретать своё уникальное решение на каждую задачу...
| | |
| |
| 2.5, Аноним (1), 23:29, 09/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Там сгенерированный си-парсер. Т.е. дело не в си, а в том, как этот парсер описан в большей мере. На деле это намного хуже, чем звучит. Но довольно эфективно, этого не отнять.
| | |
| |
| 3.10, Анонин (?), 23:42, 09/10/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Дело и в криворуких кодерах, которые в парсере использовали signed int, а в track_set_index не добавили проверку "i >= 0". И в сишке, которая не проверяет выход за границы массива.
| | |
|
| 2.53, FF (?), 11:40, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
> Это в стиле противосишников – изобретать своё уникальное решение на каждую задачу, уже реализованную на Си...
> Для преобразования строки в число используется функция atoi
тут как раз свой велосипед был бы к месту, я даже сейчас её не использую (в Go)
| | |
|
| 1.7, Аноним (7), 23:35, 09/10/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
C 76.5%
Не удивительно. Типичное integer overflow.
С ядерным Ганди, это было веселее, а тут как-то грустно((
| | |
| |
| |
| 3.49, Аноним (7), 10:34, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Да, возможно веселая придуманная байка.
А это реальная невеселая уязвимость.
Причем ошибка детская (обе ошибки, архитектурная с выбором типа и пропущенная проверка).
Можно было бы попробовать включать -ftrapv или -fwrapv хотя бы в дебаге и тестах.
Но вторая опция кажется не очень надежная, а тесты надо делать fuzzy...
В общем задача совсем не тривиальная ((
| | |
| |
| 4.83, Аноним (84), 03:30, 11/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Написать свою реализацию Increase/Decrease? Да не, мы пару тактов процессора сэкономим.
| | |
|
|
|
| 1.8, Анонин (?), 23:38, 09/10/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Нафига они вообще использовали int для INDEX?
Разве cue sheet допускает там отрицательные индексы?
Чем им unsigned не подошел?
| | |
| |
| 2.13, Карлос Сношайтилис (ok), 23:53, 09/10/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ошиблись. Идеальных разработчиков не бывает. Кто-то чаще лажает, кто-то реже.
Проблема в языке, который позволяет такие примитивные ошибки
| | |
| |
| 3.15, Аноним (7), 00:11, 10/10/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Так водителей всех идеальных тоже не бывает.
Зато как получат штраф в 5-10% от средней зарплаты, сразу улучшаются навыки и распознавания знаков, и внимательность для всех цветов светофоров.
Но да, заборчики отделяющие проезжую часть от тротуара тоже важны.
| | |
| |
| 4.36, Аноним (36), 06:13, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Чтобы устанавливать штрафы, нужно начать платить зарплату тем, чей код бесплатно используешь. А кому это надо?
| | |
| |
| 5.52, Аноним (7), 11:15, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– | |
Так многим и платят, посмотри сколько разрабов ядра и других крупных проектов на зряплате корпов.
Но ты прав, штраф тут не помогут.
А вот введение каких-то правил... Что-то типа мисры, но не настолько сложное.
Или внедрить проверки на этап компиляции.
Например
- Каждая с либа которая используется в нашем проекте должна проходить Valgrind или другой стат. анализатор
- Если собираем Clangʼом используем -fcatch-undefined-behavior для тестов
- Для CI крутим разные стат и fuzzy тесты
Но это реально сложно(
| | |
|
|
| 3.17, Аноним (28), 00:14, 10/10/2023 [^] [^^] [^^^] [ответить]
| +4 +/– |
Тем не менее, использование signed int налево и направо — ужасно плохая практика. Это только вопрос времени, когда она вылезет где-нибудь боком.
| | |
| |
| 4.55, FF (?), 11:45, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
я наоборот использую signed даже где будет только unsigned, чтобы потом наоборот в ожидаемое unsigned не залетело signed. благо 64 бит хватает, в отличие от 32.
| | |
| |
| 5.56, Анонин (?), 12:05, 10/10/2023 [^] [^^] [^^^] [ответить]
| +1 +/– |
Но ты же добавляешь проверки, что значение не отрицательное перед использованием? Правда же?
| | |
| |
| 6.76, FF (?), 21:41, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Разумеется. Особенно после того как стал работать на Go - там эти бесячьи проверки порой 80% строк функции
| | |
|
| 5.62, Аноним (28), 13:49, 10/10/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> благо 64 бит хватает, в отличие от 32
Воот, лень про это было писать: в 16-битную эпоху ещё экономили, в 32-битную расслабились, а теперь и вовсе…
| | |
|
| 4.71, MaleDog (?), 18:58, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Иногда signed int используется для того чтобы положительным результатом вернуть значение, а отрицательным код ошибки. Иначе придется возвращать значение через указатель. Компиляторы кстати могут предупреждать о преобразованиях:
test.c:9:14: warning: conversion to ‘uint32_t’ {aka ‘unsigned int’} from ‘int32_t’ {aka ‘int’} may change the sign of the result [-Wsign-conversion]
Кто бы еще за этим следил бы. Обычно наоборот включают блокировку таких сообщений.
| | |
| |
| 5.73, Аноним (28), 20:26, 10/10/2023 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Иногда signed int используется для того чтобы положительным результатом вернуть значение, а отрицательным код ошибки.
Вот за это сишников надо не то что убивать, а пытать бесконечно.
Значение должно использоваться для того, чтобы вернуть значение, И ВСЁ.
Но нет, они же до сих пор полтора регистра и десять байтов памяти экономят.
| | |
| |
| 6.80, MaleDog (?), 01:38, 11/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Не все сишники пишут под x64_86 и не то чтобы было большой проблемой проверить на >0 и привести к нужному типу. Ну и не все представляют, что завтра его либа станет использоваться в миллионе проектов ее использование расширится за пределы заложенные разработчиком.
Ну и есть люди, которые портируют не разбираясь в вопросе. К примеру кто-то написал драйвер датчика i2c под arduino, а следом кто-то пишет модуль ядра linux.
| | |
| |
| 7.81, Аноним (84), 03:26, 11/10/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Не все сишники пишут под x64_86 и не то чтобы было большой проблемой проверить на >0 и привести к нужному типу.
Это совершенно не важно, подо что они пишут. Передача кода ошибки (и самого факта ошибки) в результатах вызова функции — это даже в ассемблере 8086 было экономией на спичках (и в нормальных языках не использовалось).
У нас есть куча регистров. У нас есть миллион мегабайт памяти (которую мы бездарно транжирим). Но в бутылочное горлышко eax (ax, rax) мы постараемся протащить всё!
| | |
|
| 6.87, Аноним (87), 13:36, 11/10/2023 [^] [^^] [^^^] [ответить]
| +/– | |
> Но нет, они же до сих пор полтора регистра и десять байтов памяти экономят.
Ага, а потом вот такие "программисты" пишут жирный код и "десять байтов" накапливаются по всему кода в разных частях, затем в разных программах и тд. А потом удивляемся чего это новые программы столько жрут при том же функционале.
| | |
|
|
|
| 3.54, FF (?), 11:42, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
проблема в электричестве, которое питает железо, позволяющее выполнять машинные инструкции без проверки границы буфера
| | |
|
| 2.91, Anonymous_3680 (?), 15:12, 12/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Ты не поверишь, но да, бывают - в особенности встречаетсая на дисках с непрерывным переходом из одного трека в другой.
| | |
|
| 1.16, Аноним (16), 00:12, 10/10/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Вы обратили внимание сколько сервисов надо остановить чтобы это отключить? Systemd развращает и поощряет, если ты сделал софтину и не создал для нее 15 сервисов, то потратил время зря. С баш-портянками никто такого бы не наворотил. Ну если и наворотил, то оно само по себе сломалось бы.
| | |
| |
| 2.18, Аноним (7), 00:26, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– | |
Так это же unix way для каждой мелочи делать свою программу
Write programs that do one thing and do it well.
Так и тут, каждый сервис делает что-то одно.
| | |
| |
| 3.20, Аноним (20), 01:17, 10/10/2023 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Write programs that do one thing and do it well.
Вот именно, что well.
Ну а сейчас есть одно системпшшш, которое портянками юнитов делает не well.
| | |
| 3.94, Neon (??), 03:59, 15/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Этот unix way для каждой мелочи делать свою программу как то не довел до добра сам Unix.
| | |
|
|
| 1.31, Аноним (31), 04:45, 10/10/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я думал, это в винде такая порочная мода, пихать паразитные фоновые задачи живущие своей жизнью и жрущие, а оказывается в линуксе то же самое. По умолчанию индексатор, ха, даже еще CUE-файлов, господи, зачем? Ха-ха-ха.
| | |
| |
| 2.34, Аноним (36), 06:04, 10/10/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Предварительный индекс ускоряет поиск файлов. Так делают и в Gnome (tracker), и в KDE (baloo), и в Винде (как минимум с Vista).
| | |
| |
| |
| 4.57, Аноним (57), 12:18, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Чел, спасибо что ты есть. Столько телеметрии поставлено, и для чего? Им будто плевать на пользователя.
| | |
| |
| 5.92, InuYasha (??), 17:46, 13/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
да, отключение baloo и аналогов в винде не только освободили мне до трети ЦПУ после загрузки, но и продлило жизнь ПЗУ.
| | |
|
|
|
| 2.35, Аноним (35), 06:05, 10/10/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Помню как этот гном трекер наглухо подвешивал систему при закачке фильмов на hdd.
Он пытался сканировать недокачанные файлы, получал где-то ошибку (файл-то еще не готов) и потом повторял заново
Бесконечный доступ к медленному диску блокировал все остальные операции, и при этом он в цпу себе не отказывал и жрал под 90%.
| | |
| 2.48, iPony129412 (?), 10:12, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Чтобы ты ввёл только слово, и сразу нашлось.
А не как в Windows XP — смотри на собачку 🐕
Тоже самое и касается и превьюшек файлов, с которыми несколько раз находили уязвимости в линуксах. Выполняются сами.
Такое больше десяти лет.
| | |
| |
| 3.58, Аноним (44), 12:26, 10/10/2023 [^] [^^] [^^^] [ответить]
| +2 +/– |
Всегда отключаю эти «супер-пупер-интеллектуальные» фоновые индексации.
Лучше я посмотрю на собачку пару минут, чем компьютер будет тормозить остальные 24 часа.
| | |
| |
| 4.63, Аноним (28), 13:54, 10/10/2023 [^] [^^] [^^^] [ответить]
| –1 +/– |
Нормальный индексатор просканирует диск один раз и успокоится. Но это если нормальный.
| | |
| |
| |
| 6.75, Аноним (28), 20:44, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
А что не так в винде? Там он действительно один раз просканировал и норм.
| | |
| |
| 7.93, InuYasha (??), 17:47, 13/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Ага, скачал новую собачку - и заверте- Простите, счас у всех ССД, они не вертятся (
| | |
|
|
|
|
| 3.79, MaleDog (?), 01:14, 11/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
"Заткнись с*ка, я сам знаю что мне делать с моими файлами."(c) Вряд ли большинству линуксоидов нужна функция мгновенного поиска везде и во всем. Если нужен поиск чего-то конкретного, то они либо заранее продумают как разместить файлы чтобы их было просто искать. либо напишут или подберут свою систему индексации, что будет в 100 раз эффективнее "универсальной системы". Вот я несколько лет назад писал систему индексирования почтовых архивов, где среди нескольких миллионов писем нужно было найти письма отправленные и полученные неким пользователем. И не то чтобы прям так сложно .eml распарсить.
| | |
| |
| 4.82, Аноним (84), 03:28, 11/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Мне просто абзац как нужна. Правда, не по содержимому, а по именам, но в линуксе и того нет, убогий fsearch ни разу не замена everything.
| | |
|
|
|
| 1.33, Аноним (33), 05:59, 10/10/2023 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Удивительно!!!
На днях на компе к которому подключаюсь ssh (раньше был десктопом) посмотрел какие процессы запускаются у пользователя. О ужас!
Пришлось сносить всякий shit!
А сегодня такая новость. АААААА, они за мной следят!!!!!!!1111111ААААААА
| | |
| 1.46, anonblmus (?), 09:00, 10/10/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Я этот tracker-miner забыл с какой версии убунты в обязательном пришибаю при установках и dist-upgrade. Просто потому, что польза от этой индексации околонулевая, а ресурсов оно отжирает при каждом запуске, как свинолошадь.
| | |
| 1.59, хрю (?), 12:32, 10/10/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Смысла во всех этих индексёрах, построителей превьюшек и кучи всего остального "удобного", строго нулевая. А тут ещё и дырявая. Я, конечно, понимаю что ошибаются все, но это блин текстовый файл - как можно одырявится, при работе с текстом. Это что ж тогда с бинарными происходит?!
Может действительно только хруст спасёт от расстрелов? +)
| | |
| |
| 2.69, MaleDog (?), 18:21, 10/10/2023 [^] [^^] [^^^] [ответить]
| +/– |
Не спасет. Были уже там и косяки с разбором аргументов, и выедание всей памяти, когда память под разбор HTTP-запроса выделяли по "Content-Length". Уйдут только проблемы с памятью, и то не факт, учитывая что на 100% все не перепишут, а так и будут тягать сишные библиотеки через unsafe. А даже если и перепишут, то всегда останутся узкие места, где для ускорения потребуется код на С или ASM. То же самое и к go относится.
| | |
| |
| 3.86, Аноним (84), 07:29, 11/10/2023 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> А даже если и перепишут, то всегда останутся узкие места, где для ускорения потребуется код на С или ASM.
Процессоры по пять гигагерц, но у погромистов по-прежнему узкие места для обработки строк. Ну и не только.
| | |
|
|
|
