PL Perl · 20 вопросов · ~55 мин · ⏱ Таймер 55:00 · Лёгкий ·

Операторы и приоритет

Проверяет базовое понимание темы «Операторы и приоритет»: чтение фрагментов, выбор корректной конструкции и объяснение результата без опоры на угадывание. В тесте 20 вопросов: код нужно не только читать, но и трассировать, проверять на отказ, сопоставлять несколько правдоподобных решений. Ровно 12 заданий содержат фрагменты Perl; остальные проверяют выбор подхода в реальной ситуации. Если в условии не сказано иначе, предполагаются современный Perl 5.40+, strict и warnings; внешние модули рассматриваются в указанном контексте.

Отвечено: 0 из 20

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 20 вопросов отведено 55 минут. В каждом вопросе верен только один вариант. После завершения откроются общий результат, оценки по 4 тематическим шкалам и подробный разбор.

Вопрос 1 из 20

Как завершится этот код по правилам Perl 5.40?

my $s = 'ab';
say $s x 3;
say $s . 3;

Показанный участок сработает иначе: Числовая операция даст 12 с предупреждением о нечисловой части; это не безопасный разбор ввода. Дополнительное изменение не требуется, поскольку код уже обеспечивает следующее: Перед числовым оператором строка проверяется целиком. Будут строки ababab и ab3: x повторяет строку, а точка выполняет конкатенацию. Фрагмент «Строковые операторы» завершится ошибкой до получения описанного результата; показанные операции в этом контексте недопустимы. Поведение кода сводится к одной границе механизма: Оператор x в списочном контексте может повторять список, а в скалярном — строку; контекст снова влияет на результат.

Вопрос 2 из 20

Что в этом примере с ключевыми операциями происходит на самом деле?

say '10' == 10;
say '10' eq 10;

Исходная реализация уже содержит нужную защиту: Формат проверяется до числового сравнения. Непосредственным итогом выполнения будет: Сравнение может пройти с предупреждением, хотя строка не является корректной записью числа. Оба сравнения истинны в этом примере, но первое строковое, второе строковое и проверяют разные контракты. Оба сравнения истинны в этом примере, но первое числовое, второе числовое и проверяют разные контракты. Оба сравнения истинны в этом примере, но первое числовое, второе строковое и проверяют разные контракты.

Вопрос 3 из 20

Что выведет фрагмент с убывающим целочисленным диапазоном?

my @r = (3 .. 1);
say scalar @r;

Будет выведено 1: выражение диапазона в этом месте работает как скалярный flip-flop. Диапазон с убывающими целыми в таком виде пуст, поэтому размер равен 0. Код завершится ошибкой, потому что левая граница диапазона больше правой. Массив получит значения 3, 2 и 1, поэтому будет выведено 3. В массив попадут только границы 3 и 1, поэтому будет выведено 2.

Вопрос 4 из 20

Что в этом примере с `$ok`, `$fh` и `$path` происходит на самом деле?

my $ok = open my $fh, '<', $path or die $!;

Or имеет низкий приоритет, поэтому сначала выполняется присваивание результата open, затем при ложном значении срабатывает die. Исходная реализация уже содержит нужную защиту: Скобки явно задают границы вызова и делают вариант с || однозначным. Главным результатом фрагмента станет следующее: Высокий приоритет || может связать выражение не так, как ожидает автор; в подобных конструкциях нужен or или скобки. Or имеет низкий приоритет, поэтому сначала не выполняется присваивание результата open, затем при ложном значении срабатывает die. Единственное существенное правило этого запуска — следующая оговорка: not также имеет более низкий приоритет, чем!, поэтому механическая замена может изменить разбор выражения.

Вопрос 5 из 20

Какую границу автор фрагмента «Строковые операторы» не учёл?

my $s = '10';
say $s + '2x';

Причину отказа точнее описывает соседняя граница темы: Оператор x в списочном контексте может повторять список, а в скалярном — строку; контекст снова влияет на результат. Проблема возникает в исправленном варианте: Перед числовым оператором строка проверяется целиком. Риск возникает уже в обычном результате: Будут строки ababab и ab3: x повторяет строку, а точка выполняет конкатенацию. Числовая операция даст 13 с предупреждением о нечисловой части; это не безопасный разбор ввода. Числовая операция даст 12 с предупреждением о нечисловой части; это не безопасный разбор ввода.

Вопрос 6 из 20

Обычный случай проходит. Что в блоке «Числовые сравнения» всё же сделано неверно?

my $a = '12x';
if ($a == 12) { say 'same' }

Сравнение может пройти с предупреждением, хотя строка не является корректной записью числа. Сравнение может пройти с предупреждением, хотя строка является корректной записью числа. Риск появляется после применения рекомендуемой правки: Формат проверяется до числового сравнения. Основная проблема здесь — сам результат штатного случая: Оба сравнения истинны в этом примере, но первое числовое, второе строковое и проверяют разные контракты. Сравнение не может пройти с предупреждением, хотя строка не является корректной записью числа.

Вопрос 7 из 20

Какой риск создаёт строковый диапазон от `a` до `zzzzzz`?

for my $c ('a' .. 'zzzzzz') { push @all, $c }

Строковый диапазон может породить огромный список и исчерпать память. Диапазон остановится на `z`, потому что строковые границы длиннее одного символа не поддерживаются. Интерпретатор отклонит выражение до запуска: оператор `..` допускает только числовые границы. Perl возвращает ленивый итератор и хранит в памяти только текущее строковое значение. В `@all` будет многократно записано только последнее значение диапазона.

Вопрос 8 из 20

Где находится первопричина возможного сбоя в коде с `$ok`, `$fh` и `$path`?

my $ok = open my $fh, '<', $path || die $!;

Дефект следует искать в другой оговорке: not также имеет более низкий приоритет, чем!, поэтому механическая замена может изменить разбор выражения. Основная проблема здесь — сам результат штатного случая: or имеет низкий приоритет, поэтому сначала выполняется присваивание результата open, затем при ложном значении срабатывает die. Высокий приоритет || не может связать выражение не так, как ожидает автор; в подобных конструкциях нужен or или скобки. Сбой создаёт именно предложенное исправление: Скобки явно задают границы вызова и делают вариант с || однозначным. Высокий приоритет || может связать выражение не так, как ожидает автор; в подобных конструкциях нужен or или скобки.

Вопрос 9 из 20

Почему новая версия с `$s` и `$n` устраняет исходный дефект?

die 'bad' unless $s =~ /\A[0-9]+\z/;
my $n = 0 + $s;

Правка лишь воспроизводит исходное поведение: Будут строки ababab и ab3: x повторяет строку, а точка выполняет конкатенацию. Перед строковым оператором строка проверяется целиком. Перед числовым оператором строка проверяется целиком. После изменения сохраняется прежний дефект: Числовая операция даст 12 с предупреждением о нечисловой части; это не безопасный разбор ввода. Перед числовым оператором строка проверяется по одному элементу.

Вопрос 10 из 20

Какое свойство новой версии с `$a` важно закрепить тестом?

if ($a =~ /\A[0-9]+\z/ && $a == 12) { say 'same' }

Изменение формы записи само по себе обеспечивает правило «Для чисел используют ==, <=> и родственные операторы, для строк — eq, cmp и строковые отношения». После изменения сохраняется прежний дефект: Сравнение может пройти с предупреждением, хотя строка не является корректной записью числа. Правка лишь воспроизводит исходное поведение: Оба сравнения истинны в этом примере, но первое числовое, второе строковое и проверяют разные контракты. Формат проверяется до числового сравнения. Исправленный вариант можно считать надёжным, поскольку больше не действует ограничение: Одинаковый результат на одном наборе данных не делает eq и == взаимозаменяемыми.

Вопрос 11 из 20

Почему явный числовой цикл безопаснее материализации большого диапазона?

for (my $i = $start; $i <= $end; $i++) { process($i) }

Цикл меняет порядок чисел, но расход памяти остаётся таким же, как у списка диапазона. Для потенциально большого диапазона явный цикл не создаёт весь список заранее. Каждое значение сначала добавляется в скрытый массив, который освобождается после завершения цикла. Перед первой итерацией цикл всё равно создаёт полный список чисел от `$start` до `$end`. Экономия памяти появляется только тогда, когда `process()` возвращает ложное значение.

Вопрос 12 из 20

Как исправленный код с `$ok`, `$fh` и `$path` сохраняет исходное назначение?

my $ok = open(my $fh, '<', $path) || die $!;

Скобки неявно задают границы вызова и делают вариант с || однозначным. Скобки явно задают границы вызова и делают вариант с || однозначным. Правка лишь воспроизводит исходное поведение: or имеет низкий приоритет, поэтому сначала выполняется присваивание результата open, затем при ложном значении срабатывает die. Гарантию исправления даёт исчезновение ограничения: not также имеет более низкий приоритет, чем!, поэтому механическая замена может изменить разбор выражения. После изменения сохраняется прежний дефект: Высокий приоритет || может связать выражение не так, как ожидает автор; в подобных конструкциях нужен or или скобки.

Вопрос 13 из 20

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

Основной принцип блока описывает только такой риск: Числовая операция даст 12 с предупреждением о нечисловой части; это не безопасный разбор ввода. Строковые и числовые операторы в Perl различаются; выбор оператора задаёт способ сравнения и преобразования. Для всех случаев темы подходит одно изменение: Перед числовым оператором строка проверяется целиком. Правило «Строковые и числовые операторы в Perl различаются; выбор оператора задаёт способ сравнения и преобразования» гарантирует, что ограничение «Оператор x в списочном контексте может повторять список, а в скалярном — строку; контекст снова влияет на результат» больше не проявится. Общее правило темы «Строковые операторы» сводится к частному результату: Будут строки ababab и ab3: x повторяет строку, а точка выполняет конкатенацию.

Вопрос 14 из 20

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

Всю тему можно представить как защиту от одного отказа: Сравнение может пройти с предупреждением, хотя строка не является корректной записью числа. Общее правило темы «Числовые сравнения» сводится к частному результату: Оба сравнения истинны в этом примере, но первое числовое, второе строковое и проверяют разные контракты. Весь контракт блока обеспечивает такая правка: Формат проверяется до числового сравнения. Правило «Для чисел используют ==, <=> и родственные операторы, для строк — eq, cmp и строковые отношения» гарантирует, что ограничение «Одинаковый результат на одном наборе данных не делает eq и == взаимозаменяемыми» больше не проявится. Для чисел используют ==, <=> и родственные операторы, для строк — eq, cmp и строковые отношения.

Вопрос 15 из 20

Какое правило о диапазонах в Perl сформулировано точно?

Убывающий целочисленный диапазон автоматически разворачивается и строит значения в обратном порядке. Размер диапазона можно не оценивать: Perl освобождает каждый элемент сразу после его использования. Оператор `..` в списочном контексте строит список, поэтому возможный размер диапазона нужно оценивать заранее. Оператор `..` всегда создаёт ленивый итератор, независимо от контекста выражения. Режимы strict и warnings предотвращают создание слишком большого диапазона.

Вопрос 16 из 20

Какой общий принцип темы «Связывание» переносится на другие программы?

Различие and/or и &&/|| — в приоритете, а не в логическом смысле; его учитывают рядом с присваиванием и списковыми операторами. Общее правило темы «Связывание» сводится к частному результату: or имеет низкий приоритет, поэтому сначала выполняется присваивание результата open, затем при ложном значении срабатывает die. Общее правило темы можно свести к предотвращению одного сбоя: Высокий приоритет || может связать выражение не так, как ожидает автор; в подобных конструкциях нужен or или скобки. Общее правило исчерпывается единственной правкой: Скобки явно задают границы вызова и делают вариант с || однозначным. Правило «Различие and/or и &&/|| — в приоритете, а не в логическом смысле; его учитывают рядом с присваиванием и списковыми операторами» гарантирует, что ограничение «not также имеет более низкий приоритет, чем!, поэтому механическая замена может изменить разбор выражения» больше не проявится.

Вопрос 17 из 20

Какое предостережение по теме «Строковые операторы» нельзя заменить включением strict и warnings?

Базовое правило «Строковые и числовые операторы в Perl различаются; выбор оператора задаёт способ сравнения и преобразования» автоматически снимает указанную границу. Современный Perl устраняет указанное ограничение, поэтому отдельный тест избыточен. Оператор x в списочном контексте может повторять список, а в скалярном — строку; контекст снова влияет на результат. Ограничение «Оператор x в списочном контексте может повторять список, а в скалярном — строку; контекст снова влияет на результат» исчезает, если обычный пример один раз завершился успешно. Оператор x в списочном контексте не может повторять список, а в скалярном — строку; контекст снова влияет на результат.

Вопрос 18 из 20

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

Одинаковый результат на одном наборе данных не делает eq и == взаимозаменяемыми. Ограничение «Одинаковый результат на одном наборе данных не делает eq и == взаимозаменяемыми» исчезает, если обычный пример один раз завершился успешно. После включения strict и warnings указанная граница больше не может проявиться. Базовое правило «Для чисел используют ==, <=> и родственные операторы, для строк — eq, cmp и строковые отношения» автоматически снимает указанную границу. Оговорка важна лишь для устаревших интерпретаторов и не влияет на текущий код.

Вопрос 19 из 20

Выражение `$start .. $end` перенесли из присваивания массиву в условие `if`. Что изменилось?

В скалярном контексте `..` становится оператором состояния flip-flop, а не генератором списка. Выражение возвращает количество элементов, которое имел бы соответствующий список диапазона. Оператор один раз сравнивает `$start` и `$end` и возвращает обычное логическое значение. При включённых strict и warnings условие принудительно переводится в списочный контекст. Диапазон по-прежнему строит полный список, а условие проверяет, не пуст ли он.

Вопрос 20 из 20

Как точнее всего обозначить границу безопасного использования приёма «Связывание»?

Not также имеет более низкий приоритет, чем!, поэтому механическая замена может изменить разбор выражения. Not также имеет более низкий приоритет, чем!, поэтому механическая замена не может изменить разбор выражения. Базовое правило «Различие and/or и &&/|| — в приоритете, а не в логическом смысле; его учитывают рядом с присваиванием и списковыми операторами» автоматически снимает указанную границу. Ограничение «not также имеет более низкий приоритет, чем!, поэтому механическая замена может изменить разбор выражения» исчезает, если обычный пример один раз завершился успешно. Yest также имеет более низкий приоритет, чем!, поэтому механическая замена может изменить разбор выражения.

Ответьте на все 20 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу