А⚙
Плюсы
А почему не Rust?
И будут плюсы всегда.
Я не планирую что-либо другое использовать, разве что вм на си. Но пока плюсы
Size: a a a
2020 December 01
h
А почему не Rust?
Потому что я не растоман
А⚙
И будут плюсы всегда.
Я не планирую что-либо другое использовать, разве что вм на си. Но пока плюсы
Я не планирую что-либо другое использовать, разве что вм на си. Но пока плюсы
> VM на C
А, ну то есть чтобы ну вот прям наверняка уязвимостей посадить, я понял
А, ну то есть чтобы ну вот прям наверняка уязвимостей посадить, я понял
h
Потому что я не растоман
Не надо меня вербовать пожалуйста только)
h
> VM на C
А, ну то есть чтобы ну вот прям наверняка уязвимостей посадить, я понял
А, ну то есть чтобы ну вот прям наверняка уязвимостей посадить, я понял
Ну. Вы сами меня на си давно уговаривали ведь.
Не вы. Но в этом чате. За портабилити
Не вы. Но в этом чате. За портабилити
h
> VM на C
А, ну то есть чтобы ну вот прям наверняка уязвимостей посадить, я понял
А, ну то есть чтобы ну вот прям наверняка уязвимостей посадить, я понял
Вербовка. Этап первый: Раст = безопасность
M
Я больше скажу: лучше хранить спан стринга и ссылку на исходный текст. Если тексты ожидаются здоровенные, то лучше его перекодировать в UTF32.
Обыно валидные символы для начала и середины токена не привышают значение 65500 в codepoint метрики, это значит что вместо UTF32 вполне можно обойтись 16-bit на символ (UCS-2 кодировка)
А⚙
Вербовка. Этап первый: Раст = безопасность
В контексте сравнения с C — да. Если что опыт IT-индустрии и показывает, так это то, что писать код без уязвимостей на C — это выше способностей обычного смертного
h
В контексте сравнения с C — да. Если что опыт IT-индустрии и показывает, так это то, что писать код без уязвимостей на C — это выше способностей обычного смертного
Понимаю.
Я не любитель си в принципе. Особенно с точки зрения разработки. Плоскость беее
Я не любитель си в принципе. Особенно с точки зрения разработки. Плоскость беее
А⚙
Обыно валидные символы для начала и середины токена не привышают значение 65500 в codepoint метрики, это значит что вместо UTF32 вполне можно обойтись 16-bit на символ (UCS-2 кодировка)
Ага, а потом огребать от:
* суррогатных пар
* порядка байт
* увеличение потребления памяти по сравнению с ASCII в два раза
Нет уж, UTF-16 — это отвратительный компромисс
* суррогатных пар
* порядка байт
* увеличение потребления памяти по сравнению с ASCII в два раза
Нет уж, UTF-16 — это отвратительный компромисс
M
Ага, а потом огребать от:
* суррогатных пар
* порядка байт
* увеличение потребления памяти по сравнению с ASCII в два раза
Нет уж, UTF-16 — это отвратительный компромисс
* суррогатных пар
* порядка байт
* увеличение потребления памяти по сравнению с ASCII в два раза
Нет уж, UTF-16 — это отвратительный компромисс
USC-2 без суррогатных пар. Внимательнее читайте, я ничего не говорил про UTF16
YS
Обыно валидные символы для начала и середины токена не привышают значение 65500 в codepoint метрики, это значит что вместо UTF32 вполне можно обойтись 16-bit на символ (UCS-2 кодировка)
Хмм... а почему не UTF-8 и байтовые позиции в потоке? Какая с этим проблема?
M
USC-2 без суррогатных пар. Внимательнее читайте, я ничего не говорил про UTF16
И не требует кодирования/декодирования. Это то же самое что ACSII, только размер поинта 16 бит
А⚙
USC-2 без суррогатных пар. Внимательнее читайте, я ничего не говорил про UTF16
Остальные проблемы остаются, плюс прибавляется тот факт, что не все символы представимы
M
Не внимательно читаете)
M
Вам и не нужно представлять все символы. Только валидные для идентификаторов, а они зачастую не выходят за границу 16 бит)
h
Вам и не нужно представлять все символы. Только валидные для идентификаторов, а они зачастую не выходят за границу 16 бит)
А эмодзи подпадают под эти промежутки?
M
А эмодзи подпадают под эти промежутки?
Эмодзи так же представимы и не выходят за эти границы, так как эмодзи это графемные кластеры зачастую и состоят из набора тех же 16-битовых символов, но мы их видеим как один символ на экране)
А⚙
А эмодзи подпадают под эти промежутки?
Нет, как и иероглифы