Презентация «Rust Me, I'm a Developer!»

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

Какая гадость.

Я наоборот считаю.

Так ты и в C++ не можешь(ну кроме кастов).

А всякие заморозки в язык тащить не надо, это должен решать программист.

Но при этом, на время жизни константной ссылки твоя мутабельная ссылка будет заморожена

Зачем?

Как зачем? Что бы временная константная ссылка, которую ты дал, гарантированно была действительна.

Так ты и в C++ не можешь

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

Не вижу в этом ничего прекрасного.

Это гарантирует корректность константной ссылки.

А всякие заморозки в язык тащить не надо, это должен решать программист.

Это гарантирует безопасную работу с памятью. Для языка, который хочет считаться безопасным очень полезная штука.

Если тебе надо это обойти, то всегда есть явно объявляемые unsafe секции.

Это гарантирует безопасную работу с памятью.

безопасного секса не бывает

Позвольте поинтересоваться, на основе чего сделан этот неправильный вывод?

На основе моего опыта работы с Си, С++ и Ржавчиной.

Ты серьезно этот бред несешь что-ли? Ну вот пара примеров:

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

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

что значит «корректность» ссылки в данном случае?

Что там будут одни и те же константные данные, а не какой-нибудь случайный мусор.

Многозначительная фраза, ты не мог бы развернуть свою мысль? )

Си - опасная штука и ни от чего не защищает программиста.

Дверь — штука ещё более опасная. Не боишься за яйца?

Странно, после Heartbleed еще и года не прошло, а виртуозы Си уже снова вякают.

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

Про «сломать ссылку» я честно не понимаю. Если я вас правильно понял, ржавчина гарантирует, что если где-то есть константная ссылка на объект, то менять его нельзя никому. То есть, если есть объект, который держит ссылку на какое-то свое состояние, и хочет позволить желающим это состояние почитать, то в с++ можно просто вернуть const State&, а в ржавчине так сделать нельзя. Нужно либо никому не давать доступа, либо самому отказаться от права изменять свое состояние. И как при таком ограничении писать что-то серьезнее хелловорлдов?

Если я вас правильно понял, ржавчина гарантирует, что если где-то есть константная ссылка на объект, то менять его нельзя никому.

Если есть ссылка на объект, то менять его можно только оттуда, где эта ссылка есть.

И как при таком ограничении писать что-то серьезнее хелловорлдов?

На Rust написаны движок браузера, компилятор самого Rust, и небольшая куча библиотек - это не намекает тебе, что либо твое понимание ограничений неверно, либо ограничение совсем не критичное?

А как в этом случае с потоками быть? То есть если один поток меняет объект, а второй зафризил?

На брейнфаке тоже много чего написано. И что, объявить его пригодным для серьезной разработки теперь?

Все просто, у потоков нет общего изменяемого состояния.

Подробней:

http://static.rust-lang.org/doc/master/guide-tasks.html

На брейнфаке тоже много чего написано.

Разве что тобой лично. Это объяснило бы атрофию твоего мозга.

хм интересно. Необычно, конечно, но интересно...То есть этакий LPC. Правда я там не увидел ничего, что нельзя было б сделать на тех же С++.

+ встает еще вопрос о производительности всего этого добра.

и почему всегда в пример калькулятор делают ... хм.

А по существу есть, что сказать?
Пока что rust - это всего лишь недопиленное поделие, с которым возится небольшая группа неосиляторов с++.

А как это может помешать писать серьезные программы по-твоему?

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

А по существу есть, что сказать?

Ответ по существу ты проигнорировал.

Ну или эта функция сохраняет эту константную ссылку у себя (как член класса, например), и все плохо и вообще не понятно, что должно происходить дальше. Вот пример на с++

struct Config { ... };

class ConfigManager
{
public:
    const Config* getConfig(const char* name) const;
};

class SomeSystem
{
public:
    SomeSystem(ConfigManager* cm) : _config(cm->getConfig(SYSTEM_NAME)) {}
private:
    const Config* _config;
};

Это объяснило бы атрофию твоего мозга.
Ответ по существу

Ок, если это, по-твоему, ответ по существу, то мне добавить нечего.

Ок, если это, по-твоему, ответ по существу

Я же говорю - ответ по существу ты пропустил. Два раза %)

или эта функция сохраняет эту константную ссылку у себя (как член класса, например), и все плохо и вообще не понятно, что должно происходить дальше

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

... как это же писать на rust?

Я вижу тут, как минимум, два варианта (может кто умный еще чего получше предложил, я не претендую на эксперта), раз обязательно, что бы владел конфигами именно ConfigManager:

- перевести в Ржавчину 1 в 1 и обернуть в unsafe, что бы заткнуть компилятор;

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

typedef int ConfigId;

ConfigId ConfigManager::loadConfig(const Path& path);

const Config& ConfigManager::getConfig(ConfigId config_id) const;

небольшая группа неосиляторов с++

Зачем без повода обзывать хороших людей?

По моим наблюдениям, чем лучше и глубже человек знает С++, тем больше он его ненавидит обычно))

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

тогда придется рядом с идентификатором конфига держать еще и ссылку на ConfigManager (чтобы было у кого попросить конфиг, когда он понадобится), и проблема переходит на новый уровень.
Или сделать ConfigManager синглтоном, что противоречит условию задачи.

перевести в Ржавчину 1 в 1 и обернуть в unsafe

а как же безопасность ржавчины? Или она только в теории работает?

Я почитал вводную статью про Rust, и у меня сложилось мнение, что писал ее неосилятор для неосиляторов. Я предположил, что осиляторы должны были на этом месте отсеяться. ;)

я вот понять не могу. накидал такой код

struct Point {
    x: f64,
    y: f64
}

struct PointOther {
    p: *Point,
    y: f64
}

fn main( ) {
    let mut x = Point {x: 1.0, y: 2.0};
    let t = PointOther{p: &x, y: 100.0};
    x = Point{x: 100.0, y: 10.99};
}

Он собрался с варнингами о неиспользуемых переменных. Как видно в структуру t я передаю указатель на x, а потом x запросто меняю. Так что в результате будет в t.p?

тогда придется рядом с идентификатором конфига держать еще и ссылку на ConfigManager (чтобы было у кого попросить конфиг, когда он понадобится)

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

а как же безопасность ржавчины? Или она только в теории работает?

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

Тут ты, в отличие от Си и С++, хоть явно говоришь «хэй, обратите особое внимание на этот небольшой кусок кода, я тут делаю чего-то опасное», а на остальной код можно положиться в этом плане, его корректность компилятор гарантирует.

Как видно в структуру t я передаю указатель на x, а потом x запросто меняю.

Ты использовал raw pointer - конечно, всё будет «просто».

Так что в результате будет в t.p?

100. Попробуй, кстати, распечатать его - поймешь кое-что.

Он собрался с варнингами о неиспользуемых переменных.

И не просто так.

А теперь попробуй использовать t.p, допустим, вывести t.p:

println!(«{:?}», *t.p);

Компилятор ругнется, что это небезопасная операция.

Если я правильно понимаю происходящее, то ты получаешь временную константную ссылку, которая приводится к сырому указателю и сохраняется в объекте 't' типа PointOther. Затем объект 't' умирает и время жизни ссылки заканчивается. Все, объект 'x' разморожен, его можно менять.

перевести в Ржавчину 1 в 1 и обернуть в unsafe, что бы заткнуть компилятор

...или использовать Rc, Gc, лямбду.

Ссылку на менеджер конфигурационных файлов тоже можно передать через параметры

Тогда каждый метод SomeSystem должен принимать ссылку на ConfigManager, чтобы получить доступ к своей конфигурации. Это загрязняет интерфейс и сильно усложняет жизнь пользователю SomeSystem, который не факт, что сам имеет доступ к ConfigManagerу (а если имеет, то мы снова возвращаемся к вопросу о том, как эту ссылку хранить).

обратите особое внимание на этот небольшой кусок кода, я тут делаю чего-то опасное

Вопрос в том, не превратится ли со временем любая более-менее сложная программа в один сплошной небезопасный кусок?
Я хочу увидеть простое и чистое решение на rust, но пока что вижу, что даже простейшая задача может быть решена либо неуправляемым костылем, либо отказом от основной фичи языка.

Да, туплю.

Её действительность никак не связана с возможностью модификации объекта, на который она указывает.

ну да. 100

Point{x: 100f64, y: 10.99f64}

fn main( ) {
    /* A simple loop */
    let mut x = Point {x: 1.0, y: 2.0};

    let t = PointOther{p: &x, y: 100.0};;
    x = Point{x: 100.0, y: 10.99};
    unsafe {
        println!("{:?}", *t.p);
    }

}

Как сломать-то? Ничего не ломается. Привели код, я тебя не понимаю.

Какой случайный мусор? Что ты несешь вообще?

разыменовывание действительно только в unsafe, но поменять то объект оно мне дало просто так.

Ну, видно, логика в том, что замена объекта ничего не ломает. Разыменование может сломать, и поэтому оно в unsafe.

Это пока небольшие проекты. Движок браузера разве переписали уже?

Покажи на C++ проблемный код, а то я не понимаю, как ты собрался ссылку ломать?

Это пока небольшие проекты.

Персонаж говорил «серьезнее хелловорлдов». Если для тебя движок браузера не серьезнее хелловорлда, то... ТЫ СЦУКО БОХ!!!11

Движок браузера разве переписали уже?

Его не переписывают, а пишут. Нет, его еще не закончили, но он уже вполне работает.

Разыменование может сломать

Это как? то есть понятно, что raw pointer это штука не безопасна, особенно в кривых руках, но если ее будут пользовать (а ее будут пользовать, раз оно есть), то будут и разыменовывать. И оно, конечно, может сдохнуть где-то, но тогда вернёмся ровно к тому, от чего предлагалось лекарство. разыменовывать надо -> делаем unsafe -> получаем кору.

А можно пример кода?

Костыли вы мои костыли...

Ты явно C++ не знаешь, так как ты можешь оценивать чужие знания C++