Коллекции и строки — бесплатный тест онлайн

Вопрос 1 из 20

Какой вывод допустим после запуска `keys` и чего он не доказывает?

let mut keys: Vec<_> = counts.keys().copied().collect();
keys.sort_unstable();
assert_eq!(keys, vec!["a", "b"]);

Сортировка превращает неопределённый порядок обхода HashMap в устойчивый результат теста. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки. Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Дополнительный сценарий вокруг `keys` при таком толковании уже не требуется. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Нормальный результат на одном входе позволяет распространить тот же вывод на отмену и частичное выполнение. Тогда поведение `keys` при раннем выходе выводили бы из обычного пути.

Вопрос 2 из 20

Как лучше всего описать гарантию механизма «Словари HashMap»?

HashMap::entry объединяет проверку наличия и доступ к слоту, избегая повторного поиска и конфликтующих заимствований. Entry создаёт независимую копию значения и не даёт изменяемую ссылку внутрь карты. Порядок обхода HashMap является частью стабильного публичного контракта стандартной библиотеки. Порядок обхода HashMap стабилен внутри одной версии программы. Vec гарантирует неизменность адреса элементов после выдачи ссылки на один из них. Из этого следовало бы, что иной порядок операций для «Словари HashMap» ничего не меняет.

Вопрос 3 из 20

Какое свойство «Индексация Unicode» сохранится после небольшого рефакторинга?

String можно индексировать по номеру Unicode-символа тем же синтаксисом, что и массив байтов. Тогда различия между обычным и граничным случаем для «Индексация Unicode» исчезли бы. String индексируется по Unicode-символам за постоянное время. Тогда поведение «Индексация Unicode» при раннем выходе выводили бы из обычного пути. String хранит UTF-8 и не реализует индексирование одиночным числом, потому что индекс не может однозначно означать байт, символ или графему с постоянной стоимостью. Длина String измеряется количеством символов, а не числом байтов UTF-8. Следовательно, поведение `String::from` считалось бы одинаковым для всех допустимых типов. Срез строки по любому целому индексу автоматически округляется до границы UTF-8. Поэтому ошибочный сценарий вокруг «Индексация Unicode» не проверяли бы отдельно.

Вопрос 4 из 20

На какой операции нарушается проверяемый Rust контракт?

let mut v = vec![1, 2, 3];
let first = &v[0];
v.push(4);
println!("{first}");

Компилятор примет фрагмент: у Vec заранее указана ёмкость. Значит, выполнение должно пройти через `push` без изменения сигнатуры. Такая запись допустима, так как capacity является частью логического содержимого Vec и изменяет результат сравнения. Код не компилируется: push может перераспределить буфер, поэтому активная ссылка на элемент конфликтует с изменяемым заимствованием вектора. Код считается допустимым, потому что vec сохраняет адрес буфера при любом push, потому что ссылка на элемент уже была выдана. Код компилируется, а проблема проявляется только при выполнении: push меняет только длину и никогда не затрагивает адрес элементов.

Вопрос 5 из 20

Какая правка выдержит ревью контракта «String и str»?

fn greet(name: &str) -> String { format!("Hello, {name}") }
let owned = String::from("Ferris");
let msg = greet(&owned);
println!("{msg}");

Использовать числовой индекс как индекс элемента независимо от представления данные этого фрагмента и способа хранения данных. Собирать промежуточную коллекцию на каждом шаге `greet`, даже если задача допускает заимствование или ленивый проход. Преобразовать все строки в Vec<char> независимо от профиля операций и расхода памяти. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Клонировать всю коллекцию перед `greet`, не отделяя требуемый элемент, срез или заимствованный просмотр. Принимать &str для чтения текста из String и строковых литералов; возвращать String, когда результат создаётся внутри и должен жить независимо.

Вопрос 6 из 20

Что система типов не проверит самостоятельно для механизма «Векторы Vec»?

Пустой Vec не имеет указателя, поэтому его нельзя передавать как ptr+len даже при len=0. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. После reserve ссылка на элемент остаётся допустимой для неограниченного числа push. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение. Удаление элемента HashMap не влияет на ранее сохранённые ссылки на другие элементы. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Уменьшение длины Vec автоматически уменьшает capacity и освобождает буфер. Такое рассуждение переносило бы вывод о «Векторы Vec» на неисполненную ветвь. Даже если текущей ёмкости фактически хватает, безопасный API push имеет общий контракт и компилятор не доказывает отсутствие перераспределения по runtime capacity.

Вопрос 7 из 20

Какая правка выдержит ревью контракта «Индексация Unicode»?

let text = String::from("Здравствуйте");
// let first = text[0];
println!("{}", text.chars().count());

Использовать числовой индекс как индекс элемента независимо от представления данные этого фрагмента и способа хранения данных. В результате `chars` считали бы безопасным и на путях, которых пример не выполняет. Выбирать bytes() для байтов, chars() для Unicode scalar values и специализированную библиотеку для графем; срезы по индексам делать только по проверенным границам UTF-8. Клонировать всю коллекцию перед `text`, не отделяя требуемый элемент, срез или заимствованный просмотр. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Индексировать String по байтовому номеру и считать, что один символ всегда занимает один байт. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Собирать промежуточную коллекцию на каждом шаге `text`, даже если задача допускает заимствование или ленивый проход. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым.

Вопрос 8 из 20

Какую регрессию должен ловить `chars`?

let text = "é";
assert_eq!(text.len(), 2);
assert_eq!(text.chars().count(), 1);

Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Проверка различает длину UTF-8 в байтах и число Unicode scalar values; это не число графем для всех строк. Один положительный сценарий покрывает контракт целиком, включая частичный результат и преждевременное завершение. Если код принят компилятором, отдельное наблюдение за результатом этого сценария избыточно. Успешный запуск подтверждает корректность не только этого пути, но и остальных ветвей программы.

Вопрос 9 из 20

Какие значения останутся доступными после `String::from`?

fn greet(name: &str) -> String { format!("Hello, {name}") }
let owned = String::from("Ferris");
let msg = greet(&owned);
println!("{msg}");

Код компилируется: &String коэрцируется в &str, функция читает текст без получения владения, а возвращаемая строка принадлежит вызывающему коду. Компилятор примет фрагмент: string можно индексировать по номеру Unicode-символа тем же синтаксисом, что и массив байтов. Код считается допустимым, потому что срез строки по любому целому индексу автоматически округляется до границы UTF-8. Код компилируется, но выход за границы среза всегда возвращает пустой срез без panic. Значит, выполнение должно пройти через `String::from` без изменения сигнатуры. Код компилируется, но индексация строки возвращает ближайший Unicode-символ или заменяющий знак. Значит, выполнение должно пройти через `String::from` без изменения сигнатуры.

Вопрос 10 из 20

Что произойдёт после операции `std::collections::HashMap`?

use std::collections::HashMap;
let mut counts = HashMap::new();
for word in ["a", "b", "a"] {
    *counts.entry(word).or_insert(0) += 1;
}
println!("{}", counts["a"]);

Код пройдёт проверку компилятора: entry создаёт независимую копию значения и не даёт изменяемую ссылку внутрь карты. Код печатает 2: entry выполняет поиск один раз и предоставляет изменяемую ссылку на существующее или вставленное значение. Компиляция завершится успешно: порядок обхода HashMap стабилен внутри одной версии программы. Код компилируется, но итерация HashMap сортирует ключи при первом обходе. Значит, выполнение должно пройти через `std::collections::HashMap` без изменения сигнатуры. Компилятор отвергнет фрагмент, поскольку ключ HashMap реализует Eq и Hash. До последней строки и наблюдаемого результата программа при таком разборе не доходит.

Вопрос 11 из 20

Какое ограничение языка определяет поведение «String и str»?

Срез строки по любому целому индексу автоматически округляется до границы UTF-8. Поэтому ошибочный сценарий вокруг «String и str» не проверяли бы отдельно. Длина String измеряется количеством символов, а не числом байтов UTF-8. Тогда поведение «String и str» при раннем выходе выводили бы из обычного пути. String индексируется по Unicode-символам за постоянное время. Тогда различия между обычным и граничным случаем для «String и str» исчезли бы. String можно индексировать по номеру Unicode-символа тем же синтаксисом, что и массив байтов. String владеет изменяемым UTF-8 буфером, а str — заимствованный строковый срез; &String часто автоматически приводится к &str.

Вопрос 12 из 20

Какой край контракта «Индексация Unicode» чаще всего остаётся незамеченным?

Один ожидаемый порядок ключей можно закрепить в тесте без предварительной сортировки. По этой логике отдельная проверка «Индексация Unicode» на другом входе считалась бы лишней. Диапазонный срез строки проверяет границы UTF-8 во время выполнения и паникует, если начало или конец попадает внутрь многобайтового символа. ASCII-пример подтверждает безопасность тех же байтовых индексов для любого UTF-8 текста. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Chars().nth(n) имеет постоянную стоимость, как индексирование массива. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Индекс, равный длине строки, всегда обозначает последний символ. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются.

Вопрос 13 из 20

Какая правка выдержит ревью контракта «Словари HashMap»?

use std::collections::HashMap;
let mut counts = HashMap::new();
for word in ["a", "b", "a"] {
    *counts.entry(word).or_insert(0) += 1;
}
println!("{}", counts["a"]);

Закрепить ожидаемый порядок HashMap одним успешным тестовым запуском. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Собирать промежуточную коллекцию на каждом шаге `std::collections::HashMap`, даже если задача допускает заимствование или ленивый проход. Клонировать всю коллекцию перед `std::collections::HashMap`, не отделяя требуемый элемент, срез или заимствованный просмотр. Сохранить ссылку на элемент Vec и после каждого push восстанавливать её тем же индексом без повторного заимствования. Использовать entry для атомарного по отношению к одному &mut Map шаблона «получить или вставить»; не делать отдельные contains_key и get_mut без причины.

Вопрос 14 из 20

Что Rust гарантирует при корректном использовании «Векторы Vec»?

Vec владеет непрерывным буфером, а операция, меняющая его, требует &mut Vec и не может пересекаться с активными ссылками на элементы. Сравнение Vec учитывает capacity и адрес буфера наряду с элементами. Поэтому ошибочный сценарий вокруг «Векторы Vec» не проверяли бы отдельно. Capacity является частью логического содержимого Vec и изменяет результат сравнения. Проверку ошибки для «Векторы Vec» при таком подходе заменили бы успешным примером. Порядок обхода HashMap является частью стабильного публичного контракта стандартной библиотеки. В результате «Векторы Vec» считали бы безопасным и на путях, которых пример не выполняет. Vec сохраняет адрес буфера при любом push, потому что ссылка на элемент уже была выдана. По этой логике отдельная проверка «Векторы Vec» на другом входе считалась бы лишней.

Вопрос 15 из 20

Что проверяет `push`, если не расширять вывод за пределы выполненного пути?

let mut v = vec![1, 2, 3];
let first = v[0];
v.push(4);
assert_eq!(first, 1);

Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки. Отсутствие сообщения инструмента означает, что опасная ветвь была выполнена и признана корректной. Раз тест прошёл, производительность решения тоже можно считать подтверждённой. Копирование i32 отделяет first от буфера Vec, поэтому последующий push безопасен и не меняет сохранённое значение. Результат можно считать доказательством свойства языка, даже если он зависит от конкретной библиотеки или платформы.

Вопрос 16 из 20

Какое условие способно превратить рабочий пример «Словари HashMap» в ошибочный?

Порядок обхода стандартного HashMap не является стабильным; тесты не должны сравнивать последовательность пар без сортировки или упорядоченной структуры. Удаление элемента HashMap не влияет на ранее сохранённые ссылки на другие элементы. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Тогда поведение «Словари HashMap» при раннем выходе выводили бы из обычного пути. Один ожидаемый порядок ключей можно закрепить в тесте без предварительной сортировки. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Chars().nth(n) имеет постоянную стоимость, как индексирование массива. ASCII-пример подтверждает безопасность тех же байтовых индексов для любого UTF-8 текста. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение.

Вопрос 17 из 20

Какой риск остаётся после успешной компиляции кода по теме «String и str»?

Возвращать &str на локально созданный String нельзя; заимствованный результат должен быть частью входа или статических данных. ASCII-пример подтверждает безопасность тех же байтовых индексов для любого UTF-8 текста. Chars().nth(n) имеет постоянную стоимость, как индексирование массива. Уменьшение длины Vec автоматически уменьшает capacity и освобождает буфер. Поэтому отдельный результат ошибки и отрицательный тест для этого случая не предусматриваются. Индекс, равный длине строки, всегда обозначает последний символ. Документация и тип результата тогда могут не оговаривать частичное выполнение или раннее завершение.

Вопрос 18 из 20

Как правильно прочитать результат диагностического сценария `prefix`?

fn prefix(s: &str) -> &str { &s[..1] }
assert_eq!(prefix("Rust"), "R");

Если сценарий проходит в debug-сборке, в release и на другой целевой платформе результат будет тем же. Если код принят компилятором, отдельное наблюдение за результатом этого сценария избыточно. Тогда различия между обычным и граничным случаем для `prefix` исчезли бы. Совпадение полного текста диагностики является главным и стабильным контрактом этой проверки. Диагностика инструмента сама однозначно подсказывает безопасное исправление, поэтому разбирать контракт отдельно не нужно. Функция возвращает срез входной строки; пример корректен для ASCII, но индекс 1 может не быть границей UTF-8 символа на другом вводе.

Вопрос 19 из 20

Какую несовместимость обнаружит компилятор?

let text = String::from("Здравствуйте");
// let first = text[0];
println!("{}", text.chars().count());

Сборка пройдёт, поскольку срез строки по любому целому индексу автоматически округляется до границы UTF-8. Код компилируется, а проблема проявляется только при выполнении: выход за границы среза всегда возвращает пустой срез без panic. Код компилируется, а проблема проявляется только при выполнении: индексация строки возвращает ближайший Unicode-символ или заменяющий знак. Индексация text[0] не компилируется, а chars().count() считает Unicode scalar values, не байты и не пользовательские графемы. Фрагмент успешно соберётся: string можно индексировать по номеру Unicode-символа тем же синтаксисом, что и массив байтов.

Вопрос 20 из 20

Какая правка выдержит ревью контракта «Векторы Vec»?

let mut v = vec![1, 2, 3];
let first = &v[0];
v.push(4);
println!("{first}");

Сохранить ссылку на элемент Vec и после каждого push восстанавливать её тем же индексом без повторного заимствования. Следовательно, для `push` не понадобилось бы явное предусловие. Преобразовать все строки в Vec<char> независимо от профиля операций и расхода памяти. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. По этой логике отдельная проверка `push` на другом входе считалась бы лишней. Собирать промежуточную коллекцию на каждом шаге `vec`, даже если задача допускает заимствование или ленивый проход. Клонировать всю коллекцию перед `vec`, не отделяя требуемый элемент, срез или заимствованный просмотр. Сигнатура при этом почти не меняется, однако исходное предусловие остаётся скрытым. Использовать first до push, сохранить копию элемента, либо перестроить порядок операций; резервирование ёмкости не является разрешением для borrow checker.