The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск языка программирования Rust 1.52, opennews (??), 06-Май-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


74. "Выпуск языка программирования Rust 1.52"  +2 +/
Сообщение от eganru (?), 06-Май-21, 22:45 
Скорее всего смотря что делать.

Решил я для ознакомления с Rust сделать двусвязный список со статическим размещением элементов и без их предварительной инициализации.

Если коротко - в си это просто. в rust это страх, в котором еще ошибку сделать на раз-два.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

77. "Выпуск языка программирования Rust 1.52"  –7 +/
Сообщение от Онаним (?), 06-Май-21, 22:49 
Буква "с" в 10 слове предложения - лишняя.
Ответить | Правка | Наверх | Cообщить модератору

80. "Выпуск языка программирования Rust 1.52"  +5 +/
Сообщение от Аноним (76), 06-Май-21, 22:51 
А еще сложнее задачу придумать не мог?
Пиши хелловорлд и не выпендривайся)
Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

114. "Выпуск языка программирования Rust 1.52"  –1 +/
Сообщение от Аноним (114), 07-Май-21, 02:50 
Одной строкой ;)

let mut slist = vec![];

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

121. "Выпуск языка программирования Rust 1.52"  +1 +/
Сообщение от Аноним (121), 07-Май-21, 05:18 
>let mut slist = vec![]

А вставка миллиона элементов в начало списка длиной в миллион элементов много времени займёт?

Ответить | Правка | Наверх | Cообщить модератору

127. "Выпуск языка программирования Rust 1.52"  +1 +/
Сообщение от Аноним (127), 07-Май-21, 08:34 
A это не важно, главное хруст.
Ответить | Правка | Наверх | Cообщить модератору

154. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от Аноним (154), 07-Май-21, 10:54 
В стандартной библиотеке Раста для быстрой вставки в начало вектора есть специальный Vec растущий в обе стороны - VecDeque, но быстро добавлять элементы в середину он не даёт. Так же есть и связный список. Но эти все виды коллекций автору нельзя использовать, потому что они требуют аллокатора памяти, которого на его микроконтроллере нет.
Ответить | Правка | К родителю #121 | Наверх | Cообщить модератору

122. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от Аноним (154), 07-Май-21, 05:35 
Не подходит, я видел как этот перец спрашивал как сделать его связный список.

У него уже есть весь рабочий код на C, из него он выбрал двусвязный список чтобы попробовать раст. Поэтому кусок на расте должен идеально повторять C. Это должно быть именно массив из структур содержащих сырую память и два указателя допускающих nullpointer-ы.

Я не настоящий сварщик, только говорят что все эти штуки очень не подходят для rust. Вне unsafe использовать неинициализированную память, нулевые указатели, и иметь по две изменяющие ссылки - нельзя.

Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

128. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от Аноним (127), 07-Май-21, 08:35 
То есть написать двусвязный список без всяких извращений невозможно ?
Ответить | Правка | Наверх | Cообщить модератору

136. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от eganru (?), 07-Май-21, 09:41 
То есть написать двусвязный список без всяких извращений невозможно ? - у меня не получилось. можно залезая в nightly сделать незначительно получше, но корень проблемы не исправляет.

В таком виде работает - посмотрел disasm вроде бы ничего криминального.
https://github.com/egan-ru/tesseract_ll/blob/main/src/klle.rs

Ответить | Правка | Наверх | Cообщить модератору

160. "Выпуск языка программирования Rust 1.52"  +1 +/
Сообщение от Урри (ok), 07-Май-21, 11:01 
Ну это же читать невозможно.

    pub unsafe fn addt(&mut self, new_tail : *mut klle_t<T>)
    {
        let ll : *mut klle<T> = (*self).ll.as_mut_ptr();
        let ntail : *mut klle<T> = (*new_tail).ll.as_mut_ptr();
        let otail : *mut klle<T> = (*ll).prev;

Ответить | Правка | Наверх | Cообщить модератору

256. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от Аноним (-), 08-Май-21, 20:48 
Лютый п..дец. На 'этом' реально кто-то пишет ?
Ответить | Правка | К родителю #136 | Наверх | Cообщить модератору

138. "Выпуск языка программирования Rust 1.52"  +1 +/
Сообщение от eganru (?), 07-Май-21, 09:51 
Поэтому кусок на расте должен идеально повторять C - когда были продуманы основные алгоритмы, то естественно была оглядка только на возможности типовых МК, в которых это всё применяется(грубо говоря дальше ISA load/store архитектур никто не думал).

Оказалось, что в Си нет проблем для того, чтобы работать с этим и особых знаний для реализации не требуется.

Оказалось, что в rust в лоб такие вещи решаются плохо и требуются нетривиальные знания, которые сложно нагуглить, их нет в примерах и даже скорее непонятно как искать.

Надеюсь летом довести основные алгоритмы до POC на rust. Чтобы так сказать понять, какая часть нормально, какая часть плохо.

Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

165. "Выпуск языка программирования Rust 1.52"  –1 +/
Сообщение от Ordu (ok), 07-Май-21, 11:23 
> Оказалось, что в Си нет проблем для того, чтобы работать с этим и особых знаний для реализации не требуется.

Требуется.

1. Люди до сих пор верят в превосходство списков по скорости, например. Когда берут бенчмарки, очень удивляются. Чтобы писать хорошие программы, надо очень хорошо понимать происходящее, и мало для этого прочитать Кнута.

2. Около двух третей багов, которые находят в программах -- это тупые сишные баги, которых rust позволяет легко избежать, так что "особых знаний не требуется" -- это иллюзия. Не требуется знаний, чтобы написать бажную реализацию. А вот чтобы безбажную... Вон, тут намедни была новость о том, что аудит ~400 патчей в ядро выявил, что ~40 из этих патчей было бажными. Хехе. "Не требуется знаний", ага, угу. Точно-точно. Интересно, сколько багов они пропустили в процессе этого аудита.

> Оказалось, что в rust в лоб такие вещи решаются плохо и требуются нетривиальные знания, которые сложно нагуглить, их нет в примерах и даже скорее непонятно как искать.

rustonomicon, и "rust with entirely too many linked lists". Или тебе хочется исключительно safe-кодом? Но safe-кодом, ковыряя какие-то заморочные алгоритмы, ты скорее всего утонешь в Rc, RefCell, и Option, которые будут многократно вкладываться друг в друга. Оно можно, конечно, но если твоя цель понять что такое rust, и как им пользоваться, то ты не забывай: когда ты многократно вкладываешь Rc, RefCell и Option друг в друга, ты пользуешься им не так, как им следует пользоваться. Это может быть и полезно для учебных целей, но есть другие, более простые способы освоить раст, чем писать код, который ты через две недели выкинешь, потому что поймёшь, что он бред.

Я б лучше порекомендовал, взять и написать что-нибудь, опираясь на библиотеки. Никаких unsafe'ов, никаких "статических данных" (в смысле никаких глобальных переменных, только константы, и то, только когда очень нужно). А потом, когда борроу-чекер въестся в мозги, и ты не запуская компиляции будешь предсказывать где и на что борроу-чекер начнёт ругаться, вот тогда, ты сможешь в документации к какой-нибудь знакомой библиотеке тыкнуть на ссылку src, возле функции/типа, которые делают что-то, что тебе непонятно как делать, и посмотреть как другие делают. В частности, это очень хорошо работает с std, я очень люблю читать её код, он очень поучителен. Это гораздо образовательнее, чем изобретать свои велосипеды.

Опыт C плохо ложится на rust, потому как impedance mismatch. Например, в C, работая со строками, ты будешь жонглировать ими как массивами байтов, и потом, в самых внезапных местах, ты будешь сталкиваться с тем, что не любой массив байт является валидной utf8-строкой, и тебе надо будет с этим как-то жить. В rust'е, массив байт преобразовывается в &str (ну или в String) где-то возле того места, где этот массив байт читается из файла, и именно там будут вылетать Utf8 ошибки, и именно там ты будешь их обрабатывать. Во всех остальных местах программы ни ты, ни std даже париться не будете о том, чтобы проверить валидность utf8: они гарантированно валидны, потому что проверены. Причём это будет касаться и подстрок тоже: любая подстрока будет гарантированно начинатся и заканчиваться на границах символов.

То же самое работает с указателями: в C ты указатель проверяешь на NULL в рандомных местах программы -- иногда при получении этого указателя от внешних API, иногда перед разадресацией, иногда совсем ни к селу, ни к городу, -- в rust'е ты проверяешь raw-указатель на NULL перед преобразованием его к нормальному указателю, что происходит скорее всего где-то возле того места, где ты получил этот raw-указатель. Во всех остальных местах проверки на NULL оказываются не нужными. Причём не только явные проверки не нужны, но и неявные тоже. Всё это довольно странно меняет ситуацию, и лучшего описания этому, чем impedance mismatch, я не знаю. Поэтому, пока ты мыслишь сями, ты будешь спотыкаться в rust'е на каждом шагу и борроу-чекер будет твоим врагом, а не другом.

То же самое работает в любой другой ситуации: любой объект валиден, потому что валидность его была проверена при создании. И каждое изменение объекта производится таким образом, чтобы не нарушить валидность. В то время как в C, объект может быть невалидным (просто куском неинициализированной памяти, например), и он может "внезапно" терять валидность. Внезапно для тебя, потому что, например, ты где-то недостаточно хорошо понял API, которым пользуешься. Отсутствие таких требований в C упрощает написание программы, которая скомпилируется, упрощает до того уровня, что реально никакой квалификации не надо, чтобы написать. Но с другой стороны, это резко усложняет написание программы, которая корректно работает.

И поэтому, лучше начинать не с реализации алгоритмов и структур данных из учебника, а с высокого уровня, когда ты пользуешься уже готовыми реализациями этих алгоритмов и структур данных. Вот когда ты свой импеданс подтянешь под rust'овый, когда ты поймёшь, что borrow-checker тебе не двусвязный список мешает сделать, а ругается на то, что ты потерял информацию о владельце объекта, или на то, что сейчас ты создаёшь две мутабельные ссылки на объект, открывая простор для data race, вот тогда.... вот тогда можно и своими структурами данных заняться.

Ответить | Правка | Наверх | Cообщить модератору

173. "Выпуск языка программирования Rust 1.52"  +2 +/
Сообщение от eganru (?), 07-Май-21, 12:07 
Люди до сих пор верят в превосходство списков по скорости - об этом речь не шла. речь шла о правильности алгоритма.

Очевидно, что если мне нужен какой-то алгоритм, то я сделаю именно этот алгоритм.

"Не требуется знаний", ага, угу. Точно-точно - это не имеет отношения к поднятому вопросу и я не готов обсуждать квалификацию и сложившиеся обстоятельства, которые привели в такому положению дел.

Вполне себе может быть, горели сроки и надо было срочно делать большой объем работы, при этом не хотелось бросать в подвешенном состоянии какую-то проблему - не удивительно, что какое-то вещи были плохо проверены.

Или тебе хочется исключительно safe-кодом? - нет. зачем мне safe, когда я об этом не просил?

потому что поймёшь, что он бред. - я проверил. возможно и работает. плохо, что пользоваться неудобно. а так - связный список, обернутый в MaybeUninit обернуты во wrapper. Если допилят unnamed fields и добавят существующие возможности nightly в stable станет гораздо лучше.

очень хорошо работает с std - часть функциональности, реализованная в std требует nighly для сборки. И да, естественно, я прочел всё, что смог найти по данному вопросу.

Например, в C, работая со строками, ты будешь жонглировать ими как массивами байтов - в Си нет массивов, как таковых. там только указатели. в целом в си очень простая и ограниченная функциональность. даже области видимости фактически только в полях структур.

То же самое работает с указателями: в C ты указатель проверяешь на NULL в рандомных местах программы - только в тех местах, где это нужно. где не нужно - не проверяю.

в rust'е ты проверяешь raw-указатель на NULL - в rust я смотрел disasm - можно точно также сделать, чтобы он без проверки всё, что надо преобразовал. фактически можно точно также работать с сырой памятью как и в С. муторней только. хотелось бы, чтобы попроще что-ли как-то.

Поэтому, пока ты мыслишь сями - еще раз повторяю, никто с не думает. на С просто реализовывать любые алгоритмы. хотя и не все - часть проще писать на asm.

когда ты пользуешься уже готовыми реализациями этих алгоритмов и структур данных - я привык начинать с начала, а не с середины. начало в моем понимании это то, что Вы называете алгоритмами из учебника.

Ответить | Правка | Наверх | Cообщить модератору

200. "Выпуск языка программирования Rust 1.52"  –1 +/
Сообщение от Ordu (ok), 07-Май-21, 15:25 
> Поэтому, пока ты мыслишь сями - еще раз повторяю, никто с не
> думает. на С просто реализовывать любые алгоритмы. хотя и не все
> - часть проще писать на asm.

Если ты так думаешь, значит ты думаешь на C и не умеешь думать ни на одном другом языке, вот и всё. Тебе просто не с чем сравнить, поэтому ты думаешь, что твой способ мышления единственно продуктивный.

> когда ты пользуешься уже готовыми реализациями этих алгоритмов и структур данных
> - я привык начинать с начала, а не с середины. начало
> в моем понимании это то, что Вы называете алгоритмами из учебника.

А, ну да, догматизм. Продолжай как знаешь, это твои проблемы, а не мои.

Ответить | Правка | Наверх | Cообщить модератору

202. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от Ordu (ok), 07-Май-21, 15:29 
А, кстати, цитировать бб-кодами, вместо предлагаемого форумом формата -- это тоже, потому что тебе кто-то в детстве сказал, что так правильно, и теперь тебя ничто никогда не переубедит, что можно по иному? Догматизм головного мозга?
Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

204. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от anon2000 (?), 07-Май-21, 16:06 
ты сравниваешь теплое с мягким - хруст надо сравнивать с цпп, а не с голым си
Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

211. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от Ordu (ok), 07-Май-21, 16:44 
> ты сравниваешь теплое с мягким - хруст надо сравнивать с цпп, а
> не с голым си

Кому "надо"? Я пытался разобраться с C++, чтобы уметь сравнивать раст с ним, но меня стало неудержимо рвать. Я прекратил попытки и больше не пытался. Так что с C++ я не могу сравнивать. Не, ну если ты хочешь, я могу уподобиться местным критикам rust'а, и в том же стиле поливать жидким стулом C++, не зная C++. Но толку-то с этого?

Ответить | Правка | Наверх | Cообщить модератору

137. "Выпуск языка программирования Rust 1.52"  +1 +/
Сообщение от eganru (?), 07-Май-21, 09:43 
Никакого отношения к связному списку это не имеет. Это алгоритмически другая структура.
Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

152. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от n00by (ok), 07-Май-21, 10:46 
Технически на базе массива возможно реализовать некоторые варианты списков, если использовать вместо указателей индексы элементов (оптимизатор же огого и выкинет лишнюю арифметику). Это не секрет и в литературе описано. Потому иногда читаю войны вокруг списков, в надежде увидеть подобное предложение от знатоков Rust. Но после "Одной строкой", наверное, нет смысла ждать.
Ответить | Правка | Наверх | Cообщить модератору

159. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от Egan (?), 07-Май-21, 11:01 
Можно выкинуть часть указателя, договорившись что все данные списка лежат рядом.

Но это просто секономит место. Простоты не добавит.

Ответить | Правка | Наверх | Cообщить модератору

163. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от n00by (ok), 07-Май-21, 11:09 
Замена указателя на индекс не позволит уйти от unsafe?
Ответить | Правка | Наверх | Cообщить модератору

168. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от eganru (?), 07-Май-21, 11:34 
указателя на индекс не позволит уйти от unsafe - в общем случае нет: Вы неизбежно столкнетесь с фактом, что только 2 raw pointer могут указывать на один адрес. И это unsafe. И union unsafe. И вообще куча всего unsafe.

Более того - я не хочу уйти от unsafe. Мне ясно, что это всё unsafe. Я гарантирую, что всё это проверено и работает - для этого я пишу тесты.

Я всегда хочу просто чтобы алгоритм работал прозрачно. Если за синтаксисом не видно алгоритма это плохо - это неизбежно ведет к ошибкам. Рано или поздно, так или иначе.

Ответить | Правка | Наверх | Cообщить модератору

171. "Выпуск языка программирования Rust 1.52"  +/
Сообщение от n00by (ok), 07-Май-21, 11:58 
Сама ситуация выглядит странно. Насколько я понял, исходно Вы не специалист по Rust, решили проверить возможности языка, но возникли вопросы. Казалось бы, уместно возникнуть ответам от знатоков с примерами реализации, пусть и не 1 в 1 подходящих под исходные требования. Вместо этого предлагают кардинально иное и объясняют, что списки не нужны. А ответы с кодом пишите Вы сами.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру