![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
amaraoИнтернеты говорят, что во-первых Rc<RefCell> не идиоматично для Rust (деревья правильно держать как банальные вектора, содержащие в себе вектора векторов). Во-вторых, я, в целом, всё правильно сделал.
После некоторого кумекания получилось вот так вот, и я не вижу как его сделать существенно компактнее. Может быть, можно уйти от Enum и бального true/false хватит?
Да, получилось.
Что меня смущает? Изобилие as_ref().cloned(). Ща буду думать...
После некоторого кумекания получилось вот так вот, и я не вижу как его сделать существенно компактнее. Может быть, можно уйти от Enum и бального true/false хватит?
Да, получилось.
fn mktree(source: &[Option<i32>]) -> Tree {
if source.is_empty() || source[0].is_none() {
return None;
}
let tree: Tree = new_tree(source[0].unwrap());
let mut buff = VecDeque::new();
buff.push_back((tree.as_ref().cloned(), false));
for val in source[1..].into_iter() {
let subtree = val.and_then(|val| {
let subtree = new_tree(val);
buff.push_back((subtree.as_ref().cloned(), false));
subtree
});
let (node, is_last) = buff.pop_front().unwrap();
if is_last {
node.unwrap().borrow_mut().right = subtree;
} else {
node.as_ref().unwrap().borrow_mut().left = subtree;
buff.push_front((node.as_ref().cloned(), true));
}
}
tree
}
Что меня смущает? Изобилие as_ref().cloned(). Ща буду думать...
no subject
Date: 2022-12-25 07:54 pm (UTC)И когда вам в последний раз случалось перезагружать компьютер из-за упавшего процесса в юзерспейсе?
no subject
Date: 2022-12-25 08:31 pm (UTC)no subject
Date: 2022-12-25 08:36 pm (UTC)В случае JVM даже этого не случается. Сам процесс JVM не должен падать, и критическая ошибка -- это просто exception который останавливает работу приложения.
С точки зрения пользователя разницы большой нет. С точки зрения программиста Java защищает от нескольких типов ошибок ценой потери производительности и эффективности использования памяти. Rust совмещает одно с другим.
no subject
Date: 2022-12-25 08:45 pm (UTC)Что касается Rust и Go, то если они смогли избавиться от memory leaking, как это происходит в С++, то я в этом я очень глубоко сомневаюсь и тем более по поводу вашего "смелого" утверждения о "эффективности" использования памяти!
no subject
Date: 2022-12-25 08:50 pm (UTC)Последний раз, когда я искал что-то неизбывно ужасное, я нашёл ангелов от ibm. Страшнее этого врят ли что-то найдётся.
no subject
Date: 2022-12-25 09:09 pm (UTC)no subject
Date: 2022-12-25 08:57 pm (UTC)Хе-хе =)
> Что касается Rust и Go, то если они смогли избавиться от memory leaking, как это происходит в С++
Это звучит довольно смешно после сомнений в моей компетенции.
Во-первых, memory leaking -- это вообще не проблема в современном C++. Это была и остаётся проблемой в C, где нет RAII. Проблема, которая остаётся в C++ и которая решена в Rust -- это use-after-free.
Во-вторых, Java, которую вы ставите в пример, как раз имеет проблему memory leaking потому что с garbage collection слишком легко случайно сохранить ссылку на объекты которые должны были быть удалены.
В-третьих, Go вообще не пересекается с Rust. У них принципиально разные подходы к памяти и прочим вопросам. С этой точки зрения Go работает скорее как Java.
В-четвёртых, да, Rust решает большинство проблем безопасности памяти: memory leaks, use after free, конфликты в одновременной модификации памяти из разных тредов.
no subject
Date: 2022-12-25 09:03 pm (UTC)Молодой человек, я в религиозных войнах не участвую так быть нахалом и тем более идиотом, не намерен…
no subject
Date: 2022-12-25 08:46 pm (UTC)Предлагаю его просто игнорировать. Выглядит как фидошный троллинг образца 2002 года.
no subject
Date: 2022-12-25 08:49 pm (UTC)no subject
Date: 2022-12-25 09:05 pm (UTC)no subject
Date: 2022-12-25 09:07 pm (UTC)no subject
Date: 2022-12-25 09:10 pm (UTC)no subject
Date: 2022-12-25 09:47 pm (UTC)no subject
Date: 2022-12-25 09:04 pm (UTC)Вычеркнул, без всякого сожаления…