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(). Ща буду думать...

Flat | Top-Level Comments Only

From:

eterevsky

Чуть подробнее почему Java не подходит: в ней нет настоящих generic'ов, и всё везде хранится по указателям. Дженерики есть на уровне языка, но они не компилируются в специализации и работают поверх объектов. Это означает что в джаве невозможно писать эффективный низкоуровневый код с дженериками, в отличие от C++ и Rust.

Edited Date: 2022-12-25 07:08 pm (UTC)

From:

paserbyp

У вас, например, на курсе 100 студентов пишут курсовую работу на Java. Если бы они писали бы ее на C++, то пришлось бы перегружать университетский компьютер каждые 10 минут, а так если упадет одна из 100 JVM, то перезапустить ее как два байта переслать. Еще вопросы будут?

From:

eterevsky

Да, будут. Что вы курите?

И когда вам в последний раз случалось перезагружать компьютер из-за упавшего процесса в юзерспейсе?

From:

paserbyp

Я бросил курить давно, а процесс не падает в юзерспайсе а убивает всех вокруг своего юзерспейса. На С++ такое сделать не возможно?

From:

eterevsky

Самое страшное что может случиться с C++ процессом это segfault, при котором процесс просто убивается.

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

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

Edited Date: 2022-12-25 08:37 pm (UTC)

From:

paserbyp

Я неуверен, что вы хорошо знаете о том о чем говорите, особенно о самом страшном, что может случиться с С++. Ну да Бог с вами...

Что касается Rust и Go, то если они смогли избавиться от memory leaking, как это происходит в С++, то я в этом я очень глубоко сомневаюсь и тем более по поводу вашего "смелого" утверждения о "эффективности" использования памяти!

Edited Date: 2022-12-25 08:46 pm (UTC)

From:

amarao

Последний раз, когда я искал что-то неизбывно ужасное, я нашёл ангелов от ibm. Страшнее этого врят ли что-то найдётся.

From:

paserbyp

Плохо искал. Поищи про последний outage Roblox. Может чего поймешь, хотя наврядли…

From:

eterevsky

> Я неуверен, что вы хорошо знаете о том о чем говорите

Хе-хе =)

> Что касается 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, конфликты в одновременной модификации памяти из разных тредов.