| |
| |
| 3.14, lockywolf (ok), 12:14, 16/06/2021 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
 > Как обычно, надо полагать. Data race исключаются как класс, пока ты не
> прибегаешь к unsafe, а остальное всё в твоих руках. А почему
> ты спрашиваешь? Есть основания полагать, что у него ситуация с thread-safety
> отличается от дефолтной в расте?
Ну, я помню смешные курьёзы с errno, который в стандарте переменная, но для thread-safety сделано как макрос, разворачивающийся в вызов функции. Интересно, помнили ли об этом растовики, когда писали свой crate.
| | |
| |
| 4.15, Ordu (ok), 12:38, 16/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
 > Ну, я помню смешные курьёзы с errno, который в стандарте переменная, но
> для thread-safety сделано как макрос, разворачивающийся в вызов функции.
Чё за курьёзы? Я не помню. Мне было бы интересно посмотреть, как кто-то не справился не заметить таких нюансов.
> Интересно, помнили
> ли об этом растовики, когда писали свой crate.
А, ну это общая проблема создания safe API поверх unsafe операций. Тут она несколько осложняется тем, что там unsafe будет во все поля из-за интерфейса с внешним кодом, который rustc не может проанализировать на safety, и поэтому на всякий случай считает unsafe. То есть, в unsafe будет заворачиваться слишком много, и поэтому придётся проявлять чудеса умения обходить грабли.
Да, вероятность косяков повышена. Тут ты прав.
| | |
|
| 3.38, Прорыв_запарты_фелиал (ok), 20:59, 16/06/2021 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –4 +/– |
 А вот и жертвы пропаганды нарисовались. Модель памяти раста не предполагает конкурентного доступа, а когда нет конкурентного доступа нет гонок. Тебя обманули. Меньше лозунгов ретранслируй и больше тему изучай.
Представляешь, отличается. Раз раст не может в конкурентный доступ, то любое его наличие требует unsafe, хотя unsafe к расту не имеет никакого отношения, потому как имеет как минимум другую модель памяти, даже базовые примитивы иные. Потому как это просто обёртка поверх llvm-ir и сишного интеропа с llvm.
| | |
| |
| 4.41, Ordu (ok), 21:20, 16/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +6 +/– |
> А вот и жертвы пропаганды нарисовались. Модель памяти раста не предполагает конкурентного
> доступа, а когда нет конкурентного доступа нет гонок.
race condition в расте делается элементарно. Сделай два mutex'а, и попробуй залочить их оба последовательно из параллельных потоков.
data race в расте элементарно не делается, unsafe нужен, как раз в силу этой самой модели памяти.
А конкурентный доступ есть, чтобы какую бы лапшу _тебе_ пропаганда не вешала на уши, есть Arc для менеджмента памятью в конкурентном окружении, и есть Mutex, для конкрентного доступа. Есть Send, говорящий о том, что значения данного типа можно прокидывать между потоками выполнения. Наконец, есть Sync, для типов навроде Mutex'а, которые не просто можно прокидывать между потоками, но шарить между потоками, в смысле иметь указатели на них в разных потоках одновременно.
И если Arc и Mutex -- это творения стандартной библиотеки и дают простор порассуждать, что это не раст как таковой, а библиотека к нему, то Send и Sync -- это трейты-маркеры типов, прошитые в язык, наряду с другими трейтами-маркерами формирующими модель памяти раста (чтобы это не означало), такими как Clone, Copy, ?Sized.
> Тебя обманули.
Конечно.
> Представляешь, отличается. Раз раст не может в конкурентный доступ, то любое его
> наличие требует unsafe,
Да, ты прикинь, они врут всё про безопасность: массивы тоже в расте не реализуются без unsafe'ов. Ты реально можешь заглянуть в сорцы core::slice и увидеть там как unsafe на unsafe unsafe'ом погоняет: https://doc.rust-lang.org/src/core/slice/mod.rs.html#86
| | |
|
|
|
| |
| |
| |
| 4.65, n00by (ok), 06:52, 17/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
 >> но нашёл вот это:
>> pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t
>> https://docs.rs/libc/0.2.97/libc/fn.strlen.html
> И чо? Тебя поразило в самое сердце, что для взаимодействия с внешними
> либами можно не переизобретать велосипед, а использовать решения для тех самых
> внешних либ?
Да, меня это поразило. Вы еще про Бойер-Мура напишите для строк в 2 гигабайта, что бы я спросил: а зачем?
> (для латентных ЖСкриптозников поясню - в Ржавчине char -
> это 4 байта, а String - отдельный тип в кодировке UTF-8,
> а не массив с костыл^W набором чаров)
Если убрать малознакомые мне слова и попытки манипулировать, то правильно ли я понимаю, что тут написано о невозможности обработать массив октетов средствами Раста? (но этого не может быть).
| | |
| |
| |
| |
| 7.92, Аноним (92), 14:47, 17/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
>> но нашёл вот это:
>> pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t
>> что бы я спросил: а зачем?
> Предлагаю перечитать сообщение, на которое Вы отвечали. Там был задан вопрос на
> эту тему. Если не понятно, что такое Бойер-Мур, поищите в сети.
> Если Вы не готовы дать ответ не мой вопрос, не тратьте
> время.
Предлагаю перестать читать жопой и юлить и ответить наконец на вопрос: на*ера обязательно нужно велосипедить свою реализацию операции над _чужим_ типом данных? Что бы что?
| | |
|
|
|
|
| |
| 4.67, n00by (ok), 07:01, 17/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> strlen действительно могли бы реализовать сами, но может быть, нужен
> и конкретно текущей libc.
Зачем? Вызов внешней функции существенно дороже, чем встроенный (inline) подсчёт.
> А без malloc нельзя было бы работать
> с теми кривыми сишными поделиями, которым подай аллоцированное, а освободят они
> сами естественно сишным free
Не согласен с формулировкой. Можно. Да, для этого придётся переписать malloc на Rust и следить за изменениями эталонной реализации. Либо перехватывать вызовы free(). Это решаемая задача, но в данном случае трудозатраты вряд ли оправданы, как в случае со strlen().
| | |
| |
| 5.120, Аноним (120), 01:42, 18/06/2021 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
И очень сильно и сложно приседать, чтобы ничего не ломалось при LD_PRELOAD, скажем, jemalloc, по сути вызывая написанный на расте код через FFI.
И это уже в одном шаге от переписывания libc на раст. Что на самом деле идея красивая но неосуществимая, ведь glibc ужасает не только качеством но и объемом кода
| | |
| |
| 6.124, n00by (ok), 07:10, 18/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –1 +/– |
> И очень сильно и сложно приседать, чтобы ничего не ломалось при LD_PRELOAD,
> скажем, jemalloc, по сути вызывая написанный на расте код через FFI.
Это не эквивалентно "нельзя".
> И это уже в одном шаге от переписывания libc на раст. Что
> на самом деле идея красивая но неосуществимая, ведь glibc ужасает не
> только качеством но и объемом кода
Но Си ведь небезопасный язык. Значит libc небезопасна. Следовало переписать сначала её, а потом уже всё остальное.
| | |
|
|
|
|
| |
| |
| |
| 5.66, n00by (ok), 07:00, 17/06/2021 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –1 +/– |
>> Поскольку разбираетесь, подскажите, пожалуйста, вокруг какого syscall является обёрткой функция
>> pub unsafe extern "C" fn strlen(cs: *const c_char) -> size_t
>> https://docs.rs/libc/0.2.97/libc/fn.strlen.html
>> Raw FFI bindings to platforms’ system libraries
> Не юродствуй.
> С чего бы делать обертку неполной?
Раз не подскажете номер вызова, значит strlen() не имеет отношения к обёртке, как и попытка передёрнуть -- смысла.
> Чтобы на опеннете могли поныть "Ха,
> хипстиры ниасилили даже обертку!1"?
Пока приходится ныть об уровне аргументации и качестве риторики.
| | |
| |
| 6.83, Аноним. (?), 13:38, 17/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
> Раз не подскажете номер вызова, значит strlen() не имеет отношения к обёртке,
> как и попытка передёрнуть -- смысла.
Твоя попытка передерга - тоже. Ну или ты можешь показать, где в сабже используется strlen?
>> всё равно без libc ничего не могут. Хипстеры такие хипстеры.
> Пока приходится ныть об уровне аргументации и качестве риторики.
О да.
| | |
| |
| 7.88, n00by (ok), 14:20, 17/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –1 +/– |
>> Раз не подскажете номер вызова, значит strlen() не имеет отношения к обёртке,
>> как и попытка передёрнуть -- смысла.
> Твоя попытка передерга - тоже. Ну или ты можешь показать, где в
> сабже используется strlen?
Могу назвать вопрос унылой демагогией. Бремя доказательства, что strlen() является "System call ... wrapper function", лежит на заявителе.
| | |
|
|
|
|
| |
| 4.84, Аноним. (?), 13:51, 17/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> translate.google.com <- "generally"
> Это в тему коз и апельсинов.
Так ты коза, дергаящая в своих программах сисколы напрямую?
Или очередной опеннетный апельсин-теоретик, который любит поныть (в зависимости от темы) "Пачему оно тянет еще один жирный рантай, не используя системное!© Зачем переписали?" и "А-а-а! Используют системное! Не осилили свое! Фууу!"?
| | |
|
|
|
| |
| 2.33, Аноним (-), 18:45, 16/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
> компилятор bcc,
>> llvm-bpf backend
> Начали за здравие...
Очередной опеннетный комментатор начал за здравие
>> а предлагает собственную реализацию, написанную на Rust
>> pure Rust implementation
> ... у которого под капотом тот же llvm, что и у bcc. Закончили за упокой.
А кончил посадкой в лужу ...
| | |
|
| |
| |
| |
| 4.135, burjui (ok), 15:58, 18/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +1 +/– |
 Поставил тебе плюсик, но после твоих слов никто не поверит, что это сделал не ты сам. То есть, я только что дискредитировал тебя как союзника в дебатах just for fun. Хотя, кто знает - может, это был не ты, а тот, первый Аноним, который специально хотел, чтобы все подумали, будто он сам себе их поставил, чтобы дискредитировать идею своего первого комментария. Многоходовочка, получается.
| | |
|
|
|
| |
| |
| |
| 4.104, Аноним (94), 19:49, 17/06/2021 [^] [^^] [^^^] [ответить] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Это же не выпиливание имеющихся компиляторов и замена на этот. На неподдерживаемых платформах просто не будешь писать обработчики на расте, а будешь по-старинке. И уже написанные тоже никуда не исчезнут.
Т.о. те кто хочет писать на расте получат эту возможность, а те кто не хочет - даже не заметят.
| | |
|
|
| |
| |
| 4.100, Аноним (94), 17:23, 17/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Ну зачем себя так ограничивать - там есть еще ARM, MIPS, RISC-V и куча других.
Любители старенького могут выбрать PPC или S390x. Так что есть из чего выбирать!
А какой-то M32R который дропнули даже в линуксе никто нафиг не сдался. И там есть еще куча аналогичных архитектур, которые только формально поддерживаются.
| | |
|
|
|
| 1.119, Аноним (119), 01:35, 18/06/2021 [ответить] [﹢﹢﹢] [ · · · ] [↑] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– | |
Единственный плюс раста это уродливый и упоротый цэпэпэ который от стандарта в стандарт становится размером с глобус и при этом тянет с собой сишные костыли и подпорки... это жк наверное случится и растом если он когда нибудь взлетит, но потом...
В любом случае по уродливости и упоротости синтаксиса раст занимает почетное второе место сразу за крестами
| | |
| |
| 2.132, burjui (ok), 13:33, 18/06/2021 [^] [^^] [^^^] [ответить] [↓] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +2 +/– | |
Здешнее нытьё про синтаксис уже начинает утомлять. Без семантики синтаксис не имеет смысла, вот и учите её - тогда придёт навык чтения, и все проблемы отпадут. Такое ощущение, будто половина опеннетчиков остановилась в профессиональном развитии и категорически не приемлет изменений в привычном порядке вещей. И с какой стати он вдруг стал похож на C++? Это, скорее, ML в сишной обёртке, со своей спецификой. Если тебе нужен синтаксис, как в C# или Java, то и пиши тогда на них, и забей на Rust. Новые ЯП появляются не для того, чтобы делать всё по-старому. Новая семантика - новый синтаксис.
TL;DR
Синтаксис уже человеческий, просто некоторым человекам лень перестраивать мышление.
| | |
| |
| |
| 4.147, burjui (ok), 01:37, 20/06/2021 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| –1 +/– |
Ну, если для тебя код на С++ читабельнее, то я рад, что не являюсь твоим коллегой. И, кстати, "выглядит лучше" и "читабельнее" - синонимы. Как по мне, незамеченная тобой тавтология - признак того, что ты пытаешься в этом убедить не только меня, но и себя. Впрочем, я не исключаю возможности в один прекрасный день увидеть плюсовой код, который я счёл бы читабельным. Жаль только, что плюсовики всё никак не договорятся о стиле кода, а и без того раздутый стандарт языка только разрастается с каждой итерацией, заставляя задействовать все доступные ресурсы мозга при чтении любого мало-мальски нетривиального кода, чтобы не упустить мелкие, но очень важные детали самой запутанной семантики, которую только можно найти в мире ЯП.
| | |
|
|
|
|
