Pull to refresh
17
0.6
Кашлак Андрей @andreymal

User

Send message

Вы пробовали написать низкоуровневый код на расте без unsafe?

В чём смысл вопроса? unsafe для того и существует, чтобы предоставить программисту возможность реализовывать и самостоятельно проверять вещи, которые не способен проверить safe Rust, и изолировать эти вещи от остальной программы в этих самых unsafe-блоках (в околосишечных языках абсолютно весь код является unsafe, поэтому Rust тут безопаснее)

какие именно нерешенные задачи решает этот язык.

Сочетание безопасности и скорости (языки с GC безопасные но медленные, околосишечные языки быстрые но небезопасные)

в мире, живущем по законам Мура

Во-первых, закон Мура вроде как несколько раз хоронили

Во-вторых, судя по этой фразе, именно из-за таких людей как вы появился закон Вирта)

Добавить libfoo в эти самые другие роли, не?

Может, потому что делать иначе просто нет смысла? Для немутабельной передачи с сохранением жизни исходной переменной уже есть передача по ссылке. А владение с запретом мутабельности для меня звучит как-то противоречиво, это уже как будто и не владение совсем

При передаче владения в подфункцию область жизни перемещается в эту самую подфункцию, вот и удаляется в конце области подфункции

Ну теоретически всё ещё можно пробросить pub struct LambdaHolder или pub fn give_me_your_lambda в стороннюю библиотеку (но писать ещё один громоздкий пример я не буду)

А делать две разных логики для публичных и приватных функций — по-моему только ещё больше всех запутает

Переменная может оказаться в таком сегменте

Я настолько глубоко не копал, но подозреваю, что компилятор просто не даст такое сделать

Строки, которые прописываются в строковых литералах (let s = "Hello, World!";) и предположительно будут помещены компилятором в сегмент данных, имеют другой тип &str — то есть ссылка на кусок строки без мутабельности (а точнее &'static str, что означает, что эта ссылка остаётся валидной в течение всей жизни программы)

Ну, это не создаёт никаких уязвимостей, связанных с повреждением памяти, так что нет технических причин объявлять это unsafe ¯\_(ツ)_/¯

Лямбды тоже можно таскать глобально по всей программе
struct LambdaHolder {
    func: Box<dyn Fn(i32) -> i32>,
}

fn not_lambda(a: i32) -> i32 {
    a + 2
}

fn give_me_your_lambda(l: &mut LambdaHolder, b: i32) {
    l.func = Box::new(move |a| { a + b });
}

fn main() {
    let mut l = LambdaHolder {
        func: Box::new(not_lambda),
    };
    println!("{}", &(l.func)(2));  // 4
    give_me_your_lambda(&mut l, 5);
    println!("{}", &(l.func)(2));  // 7
}

зачем оно передаётся

Потому что программист так захотел и именно так объявил в сигнатуре функции

Как функция с иммутабельным параметром

(в случае иммутабельного параметра для начала)

Я тут у вас вижу повторяющееся заблуждение. Владелец параметра может делать с ним что угодно, в том числе превратить иммутабельное значение в мутабельное:

fn my_func(v: String) {
    let mut v = v;
    v.push_str("мутирую азаза");
}

Наличие или отсутствие мутабельности у значений — это больше защита от случайных опечаток, чтобы программист случайно не сделал то что изначально не планировал (но если всё же запланировал, то он может явно объявить мутабельность как в примере выше)

А вот мутабельность в ссылках это будет уже совсем другой разговор

Так он есть прямо в посте:

fn my_func(v: String) {
    // делаем что-то с v
}

После вызова my_func(s) владельцем параметра становится функция. Когда работа функции завершается, у параметра больше не остаётся владельца. Раз владельца больше нет — объект автоматически уничтожается и освобождается связанная с ним память. Этот факт защищает от утечек памяти, а невозможность использовать параметр повторно — от use-after-free

Вы хотите вывести сигнатуру функции из тела функции — это гиблый путь, при котором любое мелкое изменение в функции может сломать обратную совместимость

Параметр передаётся не по ссылке.

Именно! А это означает, что функция получает полное владение параметром и, если захочет, может уничтожить его. А значит из этой гарантии следует, что использовать параметр после вызова функции нельзя (иначе рискуем получить use-after-free).

но функция отработала и Вернула долг!

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

И зачем?

Чтобы пользователь этой функции мог полагаться на явно объявленные гарантии, а не что-то там гадать про наличие или отсутствие долгов

Посетители Хабра и так всё это прекрасно знают, а те, от кого вам приходят письма, эту недостатью всё равно не увидят

Тысячи уязвимостей в сишных программах наглядно демонстрируют что стоит

умею ее дебажить

выяснять не стал

Ну вы лол конечно

Тогда почему такая проблема есть только у вас?

Ну значит у вас есть что-то другое, что отдаёт некорректные хостнеймы, иначе откуда их гугл взял бы

Information

Rating
1,921-st
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity