post-tree

[amarao]

Интернеты говорят, что во-первых Rc<RefCell> не идиоматично для Rust (деревья правильно держать как банальные вектора, содержащие в себе вектора векторов). Во-вторых, я, в целом, всё правильно сделал.

После некоторого кумекания получилось вот так вот, и я не вижу как его сделать существенно компактнее. Может быть, можно уйти от 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(). Ща буду думать...

Comments

[amarao]

Rust - не классический функциональный язык. Раньше все языки условно делились на два лагеря: мутация state (наследники ассемблера/с), и "не мутировать" (функциональные языки). Rust уточнил: не мутировать конкурентно состояние. Мутировать можно, shared-доступ можно, мутировать вместе - плохо.

[permeakra]

охохо. Почитай "Programming Paradigms for Dummies: What Every Programmer Should Know" от Peter Van Roy. Это раз.

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

[amarao]

Это осознанный выбор для уменьшения числа ошибок. Всё, что я видел от растовцев по этому поводу как раз сводилось к тезису, что мутировать - совершенно окей, если это происходит в одном месте. И это резко расширяет количество корректных программ, которые принимает компилятор (в сравнении с "create only").

[permeakra]

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

[amarao]

То, что ты говоришь, не похоже на то, что говорят растовцы. Вопросы производительности - дело десятое (Ordering:Relaxed позволяет творить тебе любую дичь без оглядок на соседние процессоры). Идеология, в том виде, как я её понял, состоит в том, что запись должна идти только из одного места, если тип данных специально не поддерживает другое.

Один владелец (вместе с RAII) даёт защиту от dangling pointers, а трейты для поддержки многопроцессорности у всех типов дают 'fearless concurrency' (если оно компилируется, то оно работает).

Всю боль и сложность размышления про memory ordering, гарантии, протоколы и т.д., в rust заметают в unsafe, позволяя в остальном коде жить в режиме "компилируется, значит работает" (с поправками на логику, которую rust, разумеется, не проверяет).

[permeakra]

В расте нет базовой идеологии, к сожалению. Он рос ползучим эмпиризмом, от практики. borrow checker там не единственная фишка, там еще пытаются выкинуть ООП.

Нет, вопросы производительности - не десятое дело. Если вопросы производительности не стоят, раст не нужен, можно взять скалу, котлин и прочее такое. Раст делала изначально мозилла для написания своего файрфокса, а там производительность вполне себе важна. А чтобы компилятору было проще поднимать производительность, нужно максимально урезать мутабельность в коде.