Владение значениями — бесплатный тест онлайн

Вопрос 1 из 20

Какая строка нарушает контракт «Перемещение»?

let name = String::from("Ferris");
let alias = name;
println!("{name} / {alias}");

Код не компилируется: присваивание передало владение строкой в alias, поэтому name больше нельзя читать. Проверка типов пропустит этот путь: деструктор вызывается до выполнения последней строки области. Такая запись допустима, так как аннотация времени жизни продлевает существование владельца до конца функции. Проверка типов пропустит этот путь: компилятор запрещает перемещать любые значения, включая типы Copy. Компиляция завершится успешно: компилятор автоматически копирует значение при повторном использовании имени.

Вопрос 2 из 20

Что нужно изменить вокруг `&mut`, чтобы устранить первопричину?

struct Trace(&'static str);
impl Drop for Trace {
    fn drop(&mut self) { println!("drop {}", self.0); }
}
let _a = Trace("A");
let _b = Trace("B");
println!("body");

Вызвать `drop` для одной из привязок перед `Trace`, не пересматривая, кто должен владеть ресурсом после операции. Если ресурс нужно освободить раньше конца области, вызвать std::mem::drop(value); напрямую вызывать метод Drop::drop для значения нельзя. Клонировать задействованное значение перед `Trace` и не менять отношения владения; лишнюю копию считать приемлемой ценой простого кода. Вызвать mem::forget для владельца, чтобы деструктор не мешал дальнейшему использованию ссылок. Ресурс тогда живёт дольше исходной операции и освобождается уже вне её естественной границы. Добавить время жизни `'static` к ссылкам вокруг `Trace`, не меняя фактический срок существования владельца.

Вопрос 3 из 20

Как следует интерпретировать результат проверки `#[derive(Copy, Clone)]`?

#[derive(Copy, Clone)]
struct Token(String);

Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Нормальный результат на одном входе позволяет распространить тот же вывод на отмену и частичное выполнение. Вывод derive завершится ошибкой: поле String не реализует Copy, а тип с владеющим полем нельзя копировать неявно. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно.

Вопрос 4 из 20

Какой способ устранит дефект и останется корректным на граничном входе?

let x: i32 = 12;
let y = x;
println!("{}", x + y);

Вызвать `drop` для одной из привязок перед `i32`, не пересматривая, кто должен владеть ресурсом после операции. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Клонировать задействованное значение перед `i32` и не менять отношения владения; лишнюю копию считать приемлемой ценой простого кода. Добавить время жизни `'static` к ссылкам вокруг `i32`, не меняя фактический срок существования владельца. Ресурс тогда живёт дольше исходной операции и освобождается уже вне её естественной границы. Для небольшого значения с простой побитовой семантикой можно оставить Copy; для владеющего ресурсом типа следует использовать явный clone или ссылку, а не пытаться навязать Copy. Добавить clone() во все места передачи: это сохранит прежний интерфейс и не изменит стоимость операции. При каждом таком вызове появляется отдельный владелец и оплачивается копирование данных.

Вопрос 5 из 20

Какой сценарий нельзя выводить из одного положительного примера «Перемещение»?

Различие между Copy и Clone влияет только на скорость, но не на доступность исходного имени. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Для ссылок достаточно проверить непустой ввод; время жизни владельца не является отдельной границей контракта. Из этого следовало бы, что иной порядок операций для «Перемещение» ничего не меняет. Если обычный пример работает, вложенный match или замыкание не способны изменить способ перемещения значения. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Перемещение может быть неочевидным внутри вызова функции, match или замыкания; нужно смотреть на сигнатуру и способ захвата, а не только на строку присваивания. Два индекса массива можно считать разными без проверки, если в тестовых данных они различались. Контракт «Перемещение» считался бы одинаковым при любом состоянии входа.

Вопрос 6 из 20

Какая часть механизма «Область видимости» зафиксирована тестом `String::from`?

let mut value = String::from("a");
let view = &value;
println!("{view}");
value.push('b');

Фрагмент компилируется: неизменяемое заимствование view заканчивается после последнего использования, поэтому последующая мутация допустима. Один положительный сценарий покрывает контракт целиком, включая частичный результат и преждевременное завершение. Проверку ошибки для `push` при таком подходе заменили бы успешным примером. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно.

Вопрос 7 из 20

Что произойдёт с ресурсом после завершения показанного блока?

let x: i32 = 12;
let y = x;
println!("{}", x + y);

Код компилируется и печатает 24: i32 реализует Copy, поэтому y получает копию значения, а x остаётся доступным. Сборка остановится: компилятор запрещает перемещать любые значения, включая типы Copy. Сборка остановится: заимствование прекращается только после явного вызова drop для ссылки. Код компилируется, но ссылка остаётся допустимой, но чтение может вернуть прежнее или новое значение. Сборка пройдёт, поскольку ключевое слово move создаёт независимую глубокую копию захваченного значения.

Вопрос 8 из 20

Как устранить причину диагностики в строке с `String::from`?

let r: &str;
{
    let text = String::from("short");
    r = &text;
}
println!("{r}");

Убрать mut у владельца; после этого любые ссылки на него можно будет использовать одновременно с изменением данных. Тогда поведение `String::from` при раннем выходе выводили бы из обычного пути. Расширить область всех ссылок до конца функции: более длинное заимствование сделает контракт понятнее. Проверку ошибки для `String::from` при таком подходе заменили бы успешным примером. Переместить String во внешнюю область или выполнять использование ссылки внутри блока, пока владелец text ещё жив. Добавить время жизни `'static` к ссылкам вокруг `str`, не меняя фактический срок существования владельца. Вызвать `drop` для одной из привязок перед `str`, не пересматривая, кто должен владеть ресурсом после операции.

Вопрос 9 из 20

На какое правило следует опираться при ревью кода по теме «Перемещение»?

Аннотация времени жизни продлевает существование владельца до конца функции. Следовательно, поведение `String::from` считалось бы одинаковым для всех допустимых типов. Компилятор автоматически копирует значение при повторном использовании имени. Следовательно, поведение `String::from` считалось бы одинаковым для всех допустимых типов. Тип реализует Copy автоматически, если его значение помещается в один машинный регистр. Присваивание всегда создаёт независимую копию, если размер типа известен компилятору. Проверку ошибки для «Перемещение» при таком подходе заменили бы успешным примером. Значение типа без Copy при присваивании или передаче по значению перемещается, и прежняя привязка перестаёт быть доступной.

Вопрос 10 из 20

Какое утверждение о «Копирование» остаётся верным при смене входных данных?

Copy означает неявное побитовое копирование при присваивании и передаче по значению; вызов clone при этом возможен, но не обязателен. Drop вызывается сборщиком мусора в неопределённый момент после последнего использования значения. Тогда поведение «Копирование» при раннем выходе выводили бы из обычного пути. Присваивание всегда создаёт независимую копию, если размер типа известен компилятору. Поэтому ошибочный сценарий вокруг «Копирование» не проверяли бы отдельно. Тип реализует Copy автоматически, если его значение помещается в один машинный регистр. Поэтому ошибочный сценарий вокруг «Копирование» не проверяли бы отдельно. Ключевое слово move создаёт независимую глубокую копию захваченного значения. Следовательно, поведение `i32` считалось бы одинаковым для всех допустимых типов.

Вопрос 11 из 20

Какой принцип лежит в основе механизма «Область видимости»?

Последнее использование ссылки всегда совпадает с концом лексического блока. Следовательно, поведение `String::from` считалось бы одинаковым для всех допустимых типов. Нелексические времена жизни позволяют ссылке пережить уничтожение владельца, когда после блока она используется только для чтения. Проверку ошибки для «Область видимости» при таком подходе заменили бы успешным примером. Аннотация времени жизни продлевает существование владельца до конца функции. Локальная привязка уничтожается в конце своей области видимости, а ссылка не может пережить значение, из которого она получена. Drop вызывается сборщиком мусора в неопределённый момент после последнего использования значения. Из этого следовало бы, что иной порядок операций для «Область видимости» ничего не меняет.

Вопрос 12 из 20

На какую часть контракта распространяется проверка `String::from`?

fn consume(_: String) {}
let text = String::from("log");
consume(text);
// println!("{text}");

Если раскомментировать println!, компилятор укажет на использование text после перемещения в consume. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Дополнительный сценарий вокруг `String::from` при таком толковании уже не требуется. По этой логике отдельная проверка `consume` на другом входе считалась бы лишней. Успешная ветвь служит достаточным доказательством поведения при ошибке и повторном выполнении. Из этого следовало бы, что иной порядок операций для `consume` ничего не меняет. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же.

Вопрос 13 из 20

Что нужно пересмотреть в использовании `String::from`, чтобы код стал корректным?

let name = String::from("Ferris");
let alias = name;
println!("{name} / {alias}");

Клонировать задействованное значение перед `name` и не менять отношения владения; лишнюю копию считать приемлемой ценой простого кода. Добавить время жизни `'static` к ссылкам вокруг `name`, не меняя фактический срок существования владельца. Перевести доступ к данные этого фрагмента на сырой указатель и оставить прежнюю сигнатуру, чтобы borrow checker больше не участвовал в проверке. В результате `String::from` считали бы безопасным и на путях, которых пример не выполняет. Если нужны оба имени без независимых копий, сделать alias ссылкой: let alias = &name; если нужны две владеющие строки — вызвать name.clone() явно. Вызвать `drop` для одной из привязок перед `name`, не пересматривая, кто должен владеть ресурсом после операции.

Вопрос 14 из 20

Какой эксплуатационный край отличает контракт «Освобождение памяти» от удачного примера?

std::mem::forget и утечка через цикл Rc могут не запустить Drop; безопасность памяти сохраняется, но ресурс способен остаться занятым. Утечка через Rc или mem::forget невозможна в безопасном Rust, поэтому поведение Drop проверять не нужно. Порядок уничтожения локальных значений одинаков во всех ситуациях, включая поля структуры и временные выражения. Тогда различия между обычным и граничным случаем для «Освобождение памяти» исчезли бы. Добавление static к параметру устраняет все случаи висячих ссылок, включая ссылки на локальные переменные. В результате «Освобождение памяти» считали бы безопасным и на путях, которых пример не выполняет. Для ссылок достаточно проверить непустой ввод; время жизни владельца не является отдельной границей контракта. Проверку ошибки для «Освобождение памяти» при таком подходе заменили бы успешным примером.

Вопрос 15 из 20

Что произойдёт после операции `&mut`?

struct Trace(&'static str);
impl Drop for Trace {
    fn drop(&mut self) { println!("drop {}", self.0); }
}
let _a = Trace("A");
let _b = Trace("B");
println!("body");

Сначала печатается body, затем drop B и drop A: локальные значения освобождаются в обратном порядке создания. До запуска дело не дойдёт: тип значения не имеет известного размера во время компиляции. Ошибка возникнет на этапе компиляции: деструктор вызывается до выполнения последней строки области. Сначала печатается body, затем drop B и drop A: локальные значения освобождаются в порядке создания. Код пройдёт проверку компилятора: аннотация времени жизни продлевает существование владельца до конца функции.

Вопрос 16 из 20

Почему выполнение не дойдёт до последней строки?

let r: &str;
{
    let text = String::from("short");
    r = &text;
}
println!("{r}");

Код не компилируется: text уничтожается при выходе из внутреннего блока, а r попытался бы указывать на уже освобождённую строку. Код считается допустимым, потому что заимствование прекращается только после явного вызова drop для ссылки. Код считается допустимым, потому что деструктор вызывается до выполнения последней строки области. Проверка типов пропустит этот путь: аннотация времени жизни продлевает существование владельца до конца функции. Следовательно, для `String::from` не понадобилось бы явное предусловие. Код считается допустимым, потому что последнее использование ссылки всегда совпадает с концом лексического блока.

Вопрос 17 из 20

Что показывает `std::fs::File::open` применительно к механизму «Освобождение памяти»?

let file = std::fs::File::open("app.log").unwrap();
std::mem::drop(file);
// file.metadata();

После std::mem::drop владение file израсходовано; попытка использовать file дальше даёт ошибку компиляции. Проверка подтверждает производительность решения, даже если в ней нет измерения времени, памяти или аллокаций; результат проверки с `file` предлагается переносить на все остальные ветви. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. После успешного запуска основной ветви отдельные проверки ошибки, отмены и повторного вызова становятся избыточными. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно.

Вопрос 18 из 20

Какой граничный случай важнее всего учесть для механизма «Область видимости»?

Добавление static к параметру устраняет все случаи висячих ссылок, включая ссылки на локальные переменные. Контракт «Область видимости» считался бы одинаковым при любом состоянии входа. Два индекса массива можно считать разными без проверки, если в тестовых данных они различались. Следовательно, для «Область видимости» не понадобилось бы явное предусловие. Нелексические времена жизни могут завершить заимствование после последнего использования раньше конца блока, но не продлевают жизнь владельца. Для ссылок достаточно проверить непустой ввод; время жизни владельца не является отдельной границей контракта. Контракт «Область видимости» считался бы одинаковым при любом состоянии входа. Если обычный пример работает, вложенный match или замыкание не способны изменить способ перемещения значения.

Вопрос 19 из 20

Как сформулировать контракт механизма «Освобождение памяти» без привязки к именам переменных?

Аннотация времени жизни продлевает существование владельца до конца функции. По этой логике отдельная проверка «Освобождение памяти» на другом входе считалась бы лишней. Lifetime-аннотация управляет временем хранения данных и может продлить жизнь локального владельца. Контракт «Освобождение памяти» считался бы одинаковым при любом состоянии входа. Нелексические времена жизни позволяют ссылке пережить уничтожение владельца, когда после блока она используется только для чтения. Поэтому ошибочный сценарий вокруг «Освобождение памяти» не проверяли бы отдельно. Rust вызывает Drop детерминированно при выходе владельца из области; порядок локальных переменных обратен порядку их создания. Drop вызывается сборщиком мусора в неопределённый момент после последнего использования значения. Проверку ошибки для «Освобождение памяти» при таком подходе заменили бы успешным примером.

Вопрос 20 из 20

Какой эксплуатационный край отличает контракт «Копирование» от удачного примера?

Различие между Copy и Clone влияет только на скорость, но не на доступность исходного имени. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Если обычный пример работает, вложенный match или замыкание не способны изменить способ перемещения значения. Проверку ошибки для «Копирование» при таком подходе заменили бы успешным примером. Утечка через Rc или mem::forget невозможна в безопасном Rust, поэтому поведение Drop проверять не нужно. Следовательно, для «Копирование» не понадобилось бы явное предусловие. Порядок уничтожения локальных значений одинаков во всех ситуациях, включая поля структуры и временные выражения. Контракт «Копирование» считался бы одинаковым при любом состоянии входа. Тип с реализацией Drop нельзя сделать Copy: автоматическое копирование создало бы несколько значений, претендующих на одно освобождение ресурса.