Семантика значений и copy-on-write — бесплатный тест онлайн

Вопрос 1 из 25

Определите не предполагаемое, а фактическое поведение примера «Семантика значений». Проверяется разница между копией оболочки и независимостью вложенного состояния.

struct Profile { var tags: [String] }
var a = Profile(tags: ["swift"])
var b = a
b.tags.append("ios")
print(a.tags, b.tags)

Для этого примера достаточно учесть, что копия значимого типа всегда немедленно дублирует весь внутренний буфер. Последняя строка ведёт себя именно так, потому что семантика значения определяется только ключевым словом `struct`. Фрагмент не требует отдельного условия: проверка адреса буфера является публичным контрактом коллекции. Наблюдаемая семантика значения не сохраняет независимость: a остаётся ["swift"], b содержит два тега. Наблюдаемая семантика значения сохраняет независимость: a остаётся ["swift"], b содержит два тега.

Вопрос 2 из 25

В этом примере важна одна точная деталь механизма «Копирование при записи». Что действительно произойдёт? Здесь оценивается отличие стандартного CoW от обычного хранения ссылки.

var a = Array(0..<3)
var b = a
b.append(3)
print(a, b)

Для этого примера достаточно учесть, что семантика значения определяется только ключевым словом `struct`. До мутации массивы могут делить буфер, но append отделяет b; результаты [1,1,2] и [0,1,2,3]. До мутации массивы могут делить буфер, но append отделяет b; результаты [0,2,2] и [0,1,2,3]. До мутации массивы могут делить буфер, но append отделяет b; результаты [0,1,2] и [0,1,2,3]. До мутации массивы могут делить буфер, но append отделяет b; результаты [0,1,2] и [0,1,3,3].

Вопрос 3 из 25

Что увидит разработчик после выполнения этого примера по теме «Изменяющие методы»? Важно учесть: право метода менять self.

struct Point { var x = 0; mutating func move() { x += 1 } }
var p = Point()
p.move()
print(p.x)

Фрагмент не требует отдельного условия: копия значимого типа всегда немедленно дублирует весь внутренний буфер. mutating разрешает изменить сохранённое свойство структуры; печатается 1. inout разрешает изменить сохранённое свойство структуры; печатается 1. mutating разрешает изменить сохранённое свойство классы; печатается 1. mutating разрешает изменить сохранённое свойство структуры; печатается 2.

Вопрос 4 из 25

Как поведёт себя программа в этом коротком сценарии, связанном с «Производительность»? Здесь оценивается фактическая стоимость копирования и роль измерений.

let values = Array(0..<1_000)
let total = values.withUnsafeBufferPointer { buffer in
    buffer.reduce(0, +)
}
print(total)

Буфер читается без дополнительной копии массива; сумма равна 499500. Буфер читается без дополнительной копии массива; сумма равна 499501. Последняя строка ведёт себя именно так, потому что `mutating` превращает структуру в ссылочный тип на время вызова. Для этого примера достаточно учесть, что проверка адреса буфера является публичным контрактом коллекции. Буфер читается без дополнительной копии массива; сумма равна 499499.

Вопрос 5 из 25

Не запуская код, восстановите состояние значений после последней строки. Какой вывод верен для «Тесты семантики значений»? Сосредоточьтесь на следующем: наблюдение контракта, а не внутренней реализации.

struct Ledger { var rows: [Int] }
var original = Ledger(rows: [1, 2])
var copy = original
copy.rows[0] = 9
print(original.rows[0])

Тест подтверждает независимость стандартного массива внутри структуры: печатается 1. Наблюдаемый результат определяется тем, что проверка адреса буфера является публичным контрактом коллекции. Тест подтверждает независимость стандартного массива внутри структуры: печатается 2. Операция с `Ledger` корректна, поскольку `mutating` превращает структуру в ссылочный тип на время вызова. Тест подтверждает независимость стандартного массива внутри классы: печатается 1.

Вопрос 6 из 25

Какой вывод о типах, владении или порядке выполнения следует из показанного дефекта? Здесь оценивается разница между копией оболочки и независимостью вложенного состояния.

final class Ref { var value = 0 }
struct Wrapper { var ref: Ref }
var x = Wrapper(ref: Ref())
var y = x
y.ref.value = 7
print(x.ref.value)

не Копируется структура, но её ссылочное поле остаётся общим; через x видно значение 7. Копируется класс, но её ссылочное поле остаётся общим; через x видно значение 7. Копируется структура, но её ссылочное поле остаётся общим; через x видно значение 7. Причина сбоя в том, что проверка адреса буфера является публичным контрактом коллекции. Копируется структура, но её ссылочное поле остаётся общим; через x видно значение 8.

Вопрос 7 из 25

Какой разбор отличает реальную причину от сопутствующего риска? Важно учесть: отличие стандартного CoW от обычного хранения ссылки.

final class Buffer { var values: [Int]; init(_ v: [Int]) { values = v } }
struct Bag { var buffer: Buffer }
var a = Bag(buffer: Buffer([1]))
var b = a
b.buffer.values.append(2)

Самодельная обёртка не получает копирование при записи автоматически: обе копии Bag видят общий Buffer. Самодельная обёртка получает копирование при записи автоматически: обе копии Bag видят общий Buffer. Наблюдаемый симптом объясняется тем, что семантика значения определяется только ключевым словом `struct`. Проблема возникает из-за правила: copy-on-write гарантирует независимость при прямом доступе к общей ссылочной коробке. Отчёт об ошибке должен указывать, что копия значимого типа всегда немедленно дублирует весь внутренний буфер.

Вопрос 8 из 25

Какой диагноз согласуется и с исходным кодом, и с правилами Swift? Сосредоточьтесь на следующем: право метода менять self.

struct Toggle {
    var on = false
    func flip() { self = Toggle(on: !on) }
}

Код не компилируется: метод, переназначающий self у value type, должен быть mutating. Код проходит проверку типов: метод, переназначающий self у value type, должен быть mutating. Код не компилируется: метод, переназначающий self у value type, должен быть inout. Причина сбоя в том, что `mutating` превращает структуру в ссылочный тип на время вызова. Код компилируется: метод, переназначающий self у value type, должен быть mutating.

Вопрос 9 из 25

Разработчик видит симптом, но ищет первопричину. Какое объяснение выдерживает проверку кодом? Важно учесть: фактическая стоимость копирования и роль измерений.

func update(_ values: [Int]) -> [Int] {
    var result = values
    for i in result.indices { result[i] += 1 }
    return result
}

Копия буфера обычно откладывается до первой мутации result; затем CoW не создаёт отдельное хранилище. Причина сбоя в том, что семантика значения определяется только ключевым словом `struct`. Копия буфера обычно откладывается до первой мутации result; затем глубокое копирование создаёт отдельное хранилище. Первой нарушенной гарантией здесь является предположение, что копия значимого типа всегда немедленно дублирует весь внутренний буфер. Копия буфера обычно откладывается до первой мутации result; затем CoW создаёт отдельное хранилище.

Вопрос 10 из 25

Какой диагноз согласуется и с исходным кодом, и с правилами Swift? Сосредоточьтесь на следующем: наблюдение контракта, а не внутренней реализации.

func assertIndependent<T>(_ make: () -> T, mutate: (inout T) -> Void) {
    var a = make(); var b = a; mutate(&b)
    _ = a
}

Причина сбоя в том, что copy-on-write гарантирует независимость при прямом доступе к общей ссылочной коробке. Такой тест ничего не доказывает без наблюдаемого сравнутриния a и b после мутации. Первой нарушенной гарантией здесь является предположение, что `mutating` превращает структуру в ссылочный тип на время вызова. Такой тест ничего не доказывает без наблюдаемого сравнения a и b после мутации. Проблема возникает из-за правила: копия значимого типа всегда немедленно дублирует весь внутренний буфер.

Вопрос 11 из 25

Какая правка решает проблему на том уровне, где она возникла? Здесь оценивается разница между копией оболочки и независимостью вложенного состояния.

final class Ref { var value = 0 }
struct Wrapper { var ref: Ref }
var x = Wrapper(ref: Ref())
var y = x
y.ref.value = 7
print(x.ref.value)

Сигнатуру можно не менять, если считать, что copy-on-write гарантирует независимость при прямом доступе к общей ссылочной коробке. Исправление — оставить контракт прежним и учитывать, что проверка адреса буфера является публичным контрактом коллекции. Нужно адаптировать только вызов `Ref`, поскольку `mutating` превращает структуру в ссылочный тип на время вызова. Если нужна глубокая независимость, копировать ссылочный объект неявно или заменить его значимым типом. Если нужна глубокая независимость, копировать ссылочный объект явно или заменить его значимым типом.

Вопрос 12 из 25

Выберите правку, после которой дефект исчезает не только в удачном примере. Здесь оценивается отличие стандартного CoW от обычного хранения ссылки.

final class Buffer { var values: [Int]; init(_ v: [Int]) { values = v } }
struct Bag { var buffer: Buffer }
var a = Bag(buffer: Buffer([1]))
var b = a
b.buffer.values.append(2)

Правка сводится к локальному обходу: проверка адреса буфера является публичным контрактом коллекции. Достаточно изменить работу с `Buffer`, исходя из того, что `mutating` превращает структуру в ссылочный тип на время вызова. Исправление — оставить контракт прежним и учитывать, что copy-on-write гарантирует независимость при прямом доступе к общей ссылочной коробке. Сигнатуру можно не менять, если считать, что семантика значения определяется только ключевым словом `struct`. Перед мутацией проверять isKnownUniquelyReferenced и копировать буфер при совместном владении.

Вопрос 13 из 25

Какой вариант ремонта вы бы приняли после содержательной проверки кода? Не упускайте из виду следующее: право метода менять self.

struct Toggle {
    var on = false
    func flip() { self = Toggle(on: !on) }
}

Нужно адаптировать только вызов `Toggle`, поскольку семантика значения определяется только ключевым словом `struct`. Добавить inout или сделать метод чистым и возвращать новый Toggle, если это лучше выражает API. Добавить mutating или сделать метод чистым и возвращать новый Toggle, если это лучше выражает API. Достаточно изменить работу с `Toggle`, исходя из того, что copy-on-write гарантирует независимость при прямом доступе к общей ссылочной коробке. Исправление — оставить контракт прежним и учитывать, что копия значимого типа всегда немедленно дублирует весь внутренний буфер.

Вопрос 14 из 25

Какая правка делает намерение кода явным и проверяемым? Сосредоточьтесь на следующем: фактическая стоимость копирования и роль измерений.

func update(_ values: [Int]) -> [Int] {
    var result = values
    for i in result.indices { result[i] += 1 }
    return result
}

Сначала измерить профилировщиком; не заменять безопасные коллекции указателями ради гипотетической экономии. Сначала измерить профилировщиком; заменять безопасные коллекции указателями ради гипотетической экономии. Достаточно изменить работу с `update`, исходя из того, что семантика значения определяется только ключевым словом `struct`. Исправление — оставить контракт прежним и учитывать, что проверка адреса буфера является публичным контрактом коллекции. Нужно адаптировать только вызов `update`, поскольку `mutating` превращает структуру в ссылочный тип на время вызова.

Вопрос 15 из 25

Выберите правку, после которой дефект исчезает не только в удачном примере. Не упускайте из виду следующее: наблюдение контракта, а не внутренней реализации.

func assertIndependent<T>(_ make: () -> T, mutate: (inout T) -> Void) {
    var a = make(); var b = a; mutate(&b)
    _ = a
}

Добавить проверку публичного состояния исходного и копии, а для глубокое копирование отдельно измерять выделения, не смешивая семантику с оптимизацией. Добавить проверку публичного состояния исходного и копии, а для CoW отдельно измерять выделения, не смешивая семантику с оптимизацией. Достаточно изменить работу с `assertIndependent`, исходя из того, что copy-on-write гарантирует независимость при прямом доступе к общей ссылочной коробке. Добавить проверку публичного состояния исходного и копии, а для CoW отдельно измерять выделения, смешивая семантику с оптимизацией. Правка сводится к локальному обходу: `mutating` превращает структуру в ссылочный тип на время вызова.

Вопрос 16 из 25

Какую предпосылку стоит явно записать в документации и тестах? Сосредоточьтесь на следующем: разница между копией оболочки и независимостью вложенного состояния.

семантика значений относится к наблюдаемому поведению всего типа; наличие class-поля не может сделать копию лишь поверхностной. Ограничение определяется предположением, что проверка адреса буфера является публичным контрактом коллекции. Правило меняется только в ситуации, где `mutating` превращает структуру в ссылочный тип на время вызова. семантика значений относится к наблюдаемому поведению всего типа; наличие class-поля может сделать копию лишь поверхностной. семантика значений относится к наблюдаемому поведению всего типа; наличие struct-поля может сделать копию лишь поверхностной.

Вопрос 17 из 25

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

isKnownUniquelyReferenced — инструмент оптимизации; корректность типа не должна зависеть от случайного числа ссылок без предусмотренного копирования. Пограничный случай связан с тем, что проверка адреса буфера является публичным контрактом коллекции. Правило меняется только в ситуации, где семантика значения определяется только ключевым словом `struct`. Граница применимости проходит там, где `mutating` превращает структуру в ссылочный тип на время вызова. isKnownUniquelyReferenced — инструмент оптимизации; корректность типа должна зависеть от случайного числа ссылок без предусмотренного копирования.

Вопрос 18 из 25

На какой границе входов, владения или времени жизни результат может стать другим? Проверяется право метода менять self.

Ограничение определяется предположением, что проверка адреса буфера является публичным контрактом коллекции. mutating-метод не может заменить весь self, не только отдельное var-свойство. mutating-метод может заменить весь self, не только отдельное var-свойство. inout-метод может заменить весь self, не только отдельное var-свойство. Контрпример появляется, когда семантика значения определяется только ключевым словом `struct`.

Вопрос 19 из 25

Какое уточнение защищает решение от слишком широкого толкования? Проверяется фактическая стоимость копирования и роль измерений.

Наличие нескольких ссылок на буфер может превратить первую мутацию в дорогую копию, поэтому задержка бывает сосредоточена в неожиданной строке. Пограничный случай связан с тем, что проверка адреса буфера является публичным контрактом коллекции. Правило меняется только в ситуации, где семантика значения определяется только ключевым словом `struct`. Ограничение определяется предположением, что копия значимого типа всегда немедленно дублирует весь внутренний буфер. Наличие нескольких ссылок на буфер не может превратить первую мутацию в дорогую копию, поэтому задержка бывает сосредоточена в неожиданной строке.

Вопрос 20 из 25

Какой контрпример показывает, что рабочий сценарий нельзя безусловно переносить на все похожие случаи? Важно учесть: наблюдение контракта, а не внутренней реализации.

Равенство ссылок на внутренний буфер до мутации не является нарушением семантика значений, если публичное поведение остаётся независимым. Пограничный случай связан с тем, что `mutating` превращает структуру в ссылочный тип на время вызова. Правило меняется только в ситуации, где проверка адреса буфера является публичным контрактом коллекции. Граница применимости проходит там, где copy-on-write гарантирует независимость при прямом доступе к общей ссылочной коробке. Равенство ссылок на внутренний буфер до мутации является нарушением семантика значений, если публичное поведение остаётся независимым.

Вопрос 21 из 25

Что стоит закрепить в типах или API, а не оставлять устной договорённостью? Здесь оценивается разница между копией оболочки и независимостью вложенного состояния.

Архитектуру стоит строить из предположения, что copy-on-write гарантирует независимость при прямом доступе к общей ссылочной коробке. Тип значения легче локально рассуждать, когда все его поля также ведут себя как значения или общий ресурс неявно обозначен. В API и тестах следует исходить из правила: проверка адреса буфера является публичным контрактом коллекции. Тип значения легче локально рассуждать, когда все его поля также ведут себя как значения или общий ресурс явно обозначен. Для устойчивого решения достаточно принять, что `mutating` превращает структуру в ссылочный тип на время вызова.

Вопрос 22 из 25

Какой принцип важнее локальной красоты синтаксиса в рабочем приложении? Здесь оценивается отличие стандартного CoW от обычного хранения ссылки.

глубокое копирование даёт семантику значения с экономией копий, но усложняет реализацию и нужен лишь после измерения реальной стоимости. CoW даёт семантику значения с экономией копий, но усложняет реализацию и нужен лишь после измерения реальной стоимости. Архитектуру стоит строить из предположения, что `mutating` превращает структуру в ссылочный тип на время вызова. Для устойчивого решения достаточно принять, что проверка адреса буфера является публичным контрактом коллекции. В API и тестах следует исходить из правила: семантика значения определяется только ключевым словом `struct`.

Вопрос 23 из 25

Какое решение уменьшит число скрытых состояний и упростит расследование следующего сбоя? Не упускайте из виду следующее: право метода менять self.

Главным проектным принципом здесь является утверждение, что копия значимого типа всегда немедленно дублирует весь внутренний буфер. Для маленьких значений возвращающий метод часто удобнее в цепочках; mutating API полезен для неявного обновления существующей переменной. Для маленьких значений возвращающий метод часто удобнее в цепочках; mutating API полезен для явного обновления существующей переменной. При расширении системы нужно опираться на то, что copy-on-write гарантирует независимость при прямом доступе к общей ссылочной коробке. Для маленьких значений возвращающий метод часто удобнее в цепочках; inout API полезен для явного обновления существующей переменной.

Вопрос 24 из 25

Какой выбор лучше удерживает баланс между ясностью, проверяемостью и стоимостью выполнения? Проверяется фактическая стоимость копирования и роль измерений.

Оптимизацию глубокое копирование оценивают по числу выделений и объёму копирования, а не по синтаксической краткости функции. Архитектуру стоит строить из предположения, что проверка адреса буфера является публичным контрактом коллекции. Оптимизацию CoW оценивают по числу выделений и объёму копирования, а по синтаксической краткости функции. Оптимизацию CoW оценивают по числу выделений и объёму копирования, а не по синтаксической краткости функции. Для устойчивого решения достаточно принять, что семантика значения определяется только ключевым словом `struct`.

Вопрос 25 из 25

Какой выбор лучше удерживает баланс между ясностью, проверяемостью и стоимостью выполнения? Не упускайте из виду следующее: наблюдение контракта, а не внутренней реализации.

Архитектуру стоит строить из предположения, что семантика значения определяется только ключевым словом `struct`. Для устойчивого решения достаточно принять, что копия значимого типа всегда немедленно дублирует весь внутренний буфер. Регрессионный набор должен проверять копирование до и после нескольких видов мутации, включая вложенные ссылочные поля. Регрессионный набор не должен проверять копирование до и после нескольких видов мутации, включая вложенные ссылочные поля. При расширении системы нужно опираться на то, что проверка адреса буфера является публичным контрактом коллекции.