Здравствуйте, kaa.python, Вы писали:
KP>Ожидаемо. Ты вышел и скоупа f1, количество ссылок на rcs стало равным нулю. Попробуй хранить ее где-то выше.
Вот пытаюсь создать хеш, вставить структуру. Извлечь получается только 1 раз. Как исправить? И как должна выглядеть функция get_callback — у меня что-то не получается
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, kaa.python, Вы писали:
KP>>Ожидаемо. Ты вышел и скоупа f1, количество ссылок на rcs стало равным нулю. Попробуй хранить ее где-то выше.
CU>Вот пытаюсь создать хеш, вставить структуру. Извлечь получается только 1 раз. Как исправить? И как должна выглядеть функция get_callback — у меня что-то не получается
Не связывайся с unsafe и static, это хаки которых, по идее, в коде быть не должно. Вызывается у тебя дважды толи из за того, что в структурах присутсвуют уникальные указатели, толи из за ошибки компилятора который спотыкается об уникальные указатели в статических переменных.
Я дошел вот да такого эксперементального кода, который довольно хорошо иллюстрирует ситуацию:
Здравствуйте, cl-user, Вы писали:
CU>Вот пытаюсь создать хеш, вставить структуру. Извлечь получается только 1 раз. Как исправить? И как должна выглядеть функция get_callback — у меня что-то не получается
В рассылке появился правильный ответ, если интересно – почитай. Краткий вывод: писать unsafe можно только тогда, когда понимашь модель памяти Rust очень-очень хорошо.
Здравствуйте, kaa.python, Вы писали:
KP>Не связывайся с unsafe и static, это хаки которых, по идее, в коде быть не должно.
Без static не получается задекларировать хэш, ибо замыкание требует lifetime specifier.
А со static приходится писать unsafe, ибо use of mutable static requires unsafe function or block
KP>А если заменить Option<~MyStruct> на Option<MyStruct>, то все становится хорошо:
к своему примеру как это прицепить не понимаю
KP>И на последок: зря ты пытаешься писать на Rust так, будто ты с Си работаешь.
хм, а можно конкретнее?
KP>В рассылке появился правильный ответ, если интересно – почитай.
пойду пороюсь, но может ты дашь прямую ссылку на ветку?
Здравствуйте, cl-user, Вы писали:
CU>Здравствуйте, kaa.python, Вы писали:
CU>Без static не получается задекларировать хэш, ибо замыкание требует lifetime specifier. CU>А со static приходится писать unsafe, ибо use of mutable static requires unsafe function or block
Без статика все получится замечательно, просто сделай переменную не статической, а принадлежащей какой-то задаче. В крайнем случае, запихай ее в RWARC, или как его там сейчас звать.
KP>>А если заменить Option<~MyStruct> на Option<MyStruct>, то все становится хорошо: CU>к своему примеру как это прицепить не понимаю
Легко. Сопоставление с образцом в Rust разрушающее, от этого и такой занятный эффект вышел. Я немного упорядочил свои мысли об этом тут.
KP>>И на последок: зря ты пытаешься писать на Rust так, будто ты с Си работаешь. CU>хм, а можно конкретнее?
В Rust не должно быть глобальных данных кроме тех случаев, когда без них ну совсем при совсем никак. И если уж совсем никак, то стоит взять готовые механизмы типа ARC-а. В твоем случае без глобальных данных обойтись можно.
CU>пойду пороюсь, но может ты дашь прямую ссылку на ветку?
Тут, я их вчера спросил когда осознал что не понимаю что происходит.
Здравствуйте, kaa.python, Вы писали:
KP>Без статика все получится замечательно, просто сделай переменную не статической, а принадлежащей какой-то задаче. В крайнем случае, запихай ее в RWARC, или как его там сейчас звать.
Если просто оставлять "в цепочке вызовов" — угу, работает! С ARC-ом и подобным не так всё просто (мне): замыкания не клонируются, а как указывать, что надо оперировать исключительно ссылками на замыкания, я ещё "не догоняю"
Есть структура, которая "живёт" на всём протяжении жизни программы. Пытаюсь хранить там — опять приходится задавать lifetime parameter. Остановился вот на таком:
lib.rs:38:15: 38:17 error: use of undeclared lifetime name `'a`
lib.rs:38 impl Drop<'a> for MyStruct {
Вот теперь ищу как в объявлении
impl Drop for MyStruct {
fn drop(&mut self) {
задать этот самый lifetime parameter.
KP>В Rust не должно быть глобальных данных кроме тех случаев, когда без них ну совсем при совсем никак. И если уж совсем никак, то стоит взять готовые механизмы типа ARC-а. В твоем случае без глобальных данных обойтись можно.
Здравствуйте, cl-user, Вы писали:
CU>Если просто оставлять "в цепочке вызовов" — угу, работает! С ARC-ом и подобным не так всё просто (мне): замыкания не клонируются, а как указывать, что надо оперировать исключительно ссылками на замыкания, я ещё "не догоняю"
Ты бы приводил кусок компилируемого кода, потому как по кусочку не возможно понять что у тебя в действительности происходит.
Почти всё заработало. Остался один косяк.
Сейчас есть вот такой код:
pub type Callback<'a> = 'a |~[~str]|: -> ~str;
...
pub fn registr_callback(&mut self, name: ~str, callback: Callback<'a>) {
self.callbacks.insert(name.clone(), callback); // вставка в хеш-таблицуunsafe {
let callback = self.callbacks.find(&name); // а здесь достаём указатель...
match callback {
Some(cc) => {
name.with_c_str(|s| {
// чтобы вот здесь передать
_ext_createcommand(to_unsafe_ptr(cc),...);
});
}
None => {}
}
}
}
И никак не могу из этого костыля сделать так:
pub fn registr_callback(&mut self, name: ~str, callback: Callback<'a>) {
self.callbacks.insert(name.clone(), callback); // вставка в хеш-таблицуunsafe {
name.with_c_str(|s| {
// вот здесь передаём ссылку на регистрацию
_ext_createcommand(to_unsafe_ptr(&callback),...);
});
}
}
всё время получаю
note: `callback` moved here because it has type `'a |~[~str]| -> ~str`, which is
a non-copyable stack closure (capture it in a new closure, e.g. `|x| f(x)`, to override)
И будет ли правильным, если я не буду клонировать ~str, а получу &str и вставлю в хеш-таблицу name.into_owned()?
Думаю эта новость многих заинтересует. Для Rust были созданы инсталляторы и необходимость в сборки из исходников отпадает. На данный момент доступны следующие инсталляторы:
Здравствуйте, kaa.python, Вы писали:
KP>Думаю эта новость многих заинтересует. Для Rust были созданы инсталляторы и необходимость в сборки из исходников отпадает. На данный момент доступны следующие инсталляторы:
Для винды инсталлятор вроде уже давно был. Сейчас судя по всему сделали для всех операционных систем.
Мне вот интересно, что они там сделали в итоге с @-указателями, Gc и Rc? Введут еще какой-то символ, или вообще удалят?
Здравствуйте, x-code, Вы писали:
XC>Мне вот интересно, что они там сделали в итоге с @-указателями, Gc и Rc? Введут еще какой-то символ, или вообще удалят?
Не, останется как и было, просто будет возможность использовать разные типы сборзщиков мусора. Да и сейчас @-указатели есть, на них же куча кода базируется:
managed_boxes — Usage of @ pointers is gated due to many planned changes to this feature. In the past, this has meant "a GC pointer", but the current implementation uses reference counting and will likely change drastically over time. Additionally, the @ syntax will no longer be used to create GC boxes.
Здравствуйте, kaa.python, Вы писали:
KP>Не, останется как и было, просто будет возможность использовать разные типы сборзщиков мусора. Да и сейчас @-указатели есть, на них же куча кода базируется: KP>
KP>managed_boxes — Usage of @ pointers is gated due to many planned changes to this feature. In the past, this has meant "a GC pointer", but the current implementation uses reference counting and will likely change drastically over time. Additionally, the @ syntax will no longer be used to create GC boxes.
KP>Так что директивы компилятору будет достаточно: KP>
#[feature(managed_boxes)]
Ну вот это и непонятно: для разных типов сборщиков мусора по идее нужны разные указатели. Или они как-то будут использовать значок @ для разных типов одновременно?
Здравствуйте, x-code, Вы писали:
XC>Ну вот это и непонятно: для разных типов сборщиков мусора по идее нужны разные указатели. Или они как-то будут использовать значок @ для разных типов одновременно?
Значка может не остатся. Будет специальная операция разыменования, с разными указателями, имеющими разные типы.
Мне так кажется, что это будет полный аналог умных указателей из С++.
Здравствуйте, x-code, Вы писали:
XC>Ну вот это и непонятно: для разных типов сборщиков мусора по идее нужны разные указатели. Или они как-то будут использовать значок @ для разных типов одновременно?
Как мне кажется, авторы еще сами не знают ответа на этот вопрос. В крайнем случае мне не попадалась на глаза информация о том, как они собираются разруливать разные типы указателей, при том что значек только один.
Сегодня вышел, на мой взгляд, интереснейший релиз Rust 0.10. Ломающих изменений в нем не очень много, зато был проведен просто грандиозный рефакторинг: две основные библиотеки libstd и libextra были разделены на полтора десятка библиотек "одной функции" в процессе чего libextra перестала сущестовать. Это хорошо в первую очередь тем, что появилась реальная возможность начать использовать Rust практически в пределах libstd (все же необходимо еще немного порезать libstd для отключения работы с задачами), а не только самого компилятора, на низком уровне, к примеру в драйверах. Сейчас как раз занимаюсь подобным экспериментом, выглядит ну очень заманчиво!