При временном чтении через изменяемую ссылку, что происходит с возможностью последующей записи через исходную ссылку?
База Hintsage
Программирование Rust
Язык Rust и безопасное системное программирование.
Темы раздела
Выберите подраздел
- 0 вопросов
Общие вопросы
Смешанные вопросы по Rust.
Открыть раздел - 49 вопросов
Rust Core
Типы, pattern matching, modules и базовая семантика.
Открыть раздел - 50 вопросов
Владение и заимствование
Ownership, borrowing, moves и правила безопасной памяти.
Открыть раздел - 50 вопросов
Времена жизни
Lifetime annotations и связи времени жизни ссылок.
Открыть раздел - 49 вопросов
Traits и generics
Traits, bounds, generics, associated types и dispatch.
Открыть раздел - 50 вопросов
Конкурентность и async
Send/Sync, threads, channels, futures и async runtime.
Открыть раздел - 50 вопросов
Обработка ошибок
Result, Option, оператор ?, panic и проектирование ошибок.
Открыть раздел - 50 вопросов
Unsafe и память
Unsafe Rust, raw pointers, FFI и инварианты безопасности.
Открыть раздел
Практика
Вопросы: Программирование Rust
Почему Rust запрещает перемещать отдельное поле из структуры, реализующей Drop?
Чем присваивание значения типа, реализующего Copy, отличается от обычного перемещения?
Разберите, какую операцию предотвращает Pin<Box<T>> для типа без Unpin и зачем это нужно. Рассмотрите код:
use std::marker::PhantomPinned;
struct Task {
value: String,
_pin: PhantomPinned,
}
fn main() {
let pinned = Box::pin(Task {
value: String::from("ready"),
_pin: PhantomPinned,
});
// let moved: Task = *pinned;
println!("{}", pinned.value);
}
Каким образом Rust предотвращает двойное освобождение значения после его перемещения в другую переменную?
Какая проверка позволяет Rust безопасно передать владение значением в другой поток?
Что именно перестаёт гарантировать Rust после преобразования ссылки в сырой указатель? Рассмотрите фрагмент:
fn main() {
let value = 42;
let ptr: *const i32 = &value;
unsafe {
println!("{}", *ptr);
}
}
В сопоставлении с образцом значение типа String оказывается недоступным после ветки: какой механизм приводит к этому и как взять данные без перемещения?
Как Cow откладывает клонирование заимствованных данных до первой мутации?
В цикле ниже items используется после обхода. Какой механизм Rust делает переменную недоступной после цикла?
fn main() {
let items = vec![String::from("a"), String::from("b")];
for item in items {
println!("{item}");
}
println!("{}", items.len());
}
Как Rust безопасно использует ссылку с более долгим временем жизни там, где требуется более короткое?
Верно ли, что ограничение T: 'static означает обязательное существование значения до завершения программы?
Перед вами функция, принимающая callback, который возвращает заимствование из своего аргумента. Объясните, какую гарантию здесь даёт for<'a>:
fn identity<'a>(value: &'a str) -> &'a str {
value
}
fn apply(
callback: impl for<'a> Fn(&'a str) -> &'a str,
text: &str,
) -> &str {
callback(text)
}
fn main() {
let text = String::from("ready");
println!("{}", apply(identity, &text));
}
Разберите последствия: что делает Rust с прежним значением владеющей переменной при присваивании ей нового значения?
Можно ли безопасно получить два изменяемых заимствования из разных частей одного среза, если граница разделения вычисляется во время выполнения?
Допустимо ли в безопасном Rust намеренно не освобождать значение, и чем это отличается от нарушения памяти?
Что перемещается при присваивании переменной типа &mut T другой переменной, и почему исходное имя после этого недоступно?
В каких случаях Rust продлевает время жизни временного значения, на которое взяли ссылку?
Что мешает типу, реализующему Drop, одновременно реализовать Copy?
Что определяет, захватит ли замыкание переменную по ссылке или переместит её?
Показано 261–280 из 348