Команда alloc не инициализирует объект. Она только выделяет память. Именно по этой причине в Obj-C пишется MyClass *myClass = [[MyClass alloc] init], сначала выделение памяти, потом в выделенную память заноситься проинициализированный объект.
проверил первый пример и не получил никакого краша как и должно было быть, когда ты вызываешь DispatchQuue.main.async... и вызываешь в блоке instance.closure?(), то DispatchQueue будет держать ссылку на instance, который держит ссылку на closure, и когда вызывается instance.closure?(), instance все еще в памяти и так как closure держит unowned ссылку на свой класс memory cycle не возникает и никакого краша не может. Остальную часть видео не буду даже смотреть такой элементарный пример неправильный показан
Можно сделать DispatchQueue.main.asyncAfter(deadline: .now() + 2) { [unowned instance] in ... } Будет краш. А вот то что автор на 8 месяцев не озаботился поправиться, это, конечно, не дело.
1 вопрос! не скорее всего, а никогда. тк захватываются переменные, и у арс счетчики обнуляются в конце функции.. не прав? про гк тоже есть мнение, но промолчу
смысл в том что unowned - это ссылка на ячейку в памяти. ситуация: сильных ссылок нет, ячейка в памяти очищена. unowned safe обратиться к этой ячейки памяти и поймет что объекта там нет и крашнет прилу, а unowned unsafe обратиться к ячейки и, если эта ячейка уже содержит абсолютно "левый" объект то каки-то образом выдаст его. надеюсь я не наврал)
Автор, ты крутой. Так собрать и сконцентрировать полезную инфу, это дорогого стоит. Продолжай в том же духе!
Команда alloc не инициализирует объект. Она только выделяет память. Именно по этой причине в Obj-C пишется MyClass *myClass = [[MyClass alloc] init], сначала выделение памяти, потом в выделенную память заноситься проинициализированный объект.
Да, alloc выдаёт диапазон адресов в памяти, а new записывает в этот диапазон биты при помощи наших конструкторов
Лучший видос на данную тему, продолжай пилить еще видосы по другим темам, офигенно получается, лучший
Спасибо за проделанную работу
проверил первый пример и не получил никакого краша как и должно было быть, когда ты вызываешь DispatchQuue.main.async... и вызываешь в блоке instance.closure?(), то DispatchQueue будет держать ссылку на instance, который держит ссылку на closure, и когда вызывается instance.closure?(), instance все еще в памяти и так как closure держит unowned ссылку на свой класс memory cycle не возникает и никакого краша не может. Остальную часть видео не буду даже смотреть такой элементарный пример неправильный показан
Можно сделать DispatchQueue.main.asyncAfter(deadline: .now() + 2) { [unowned instance] in ... }
Будет краш.
А вот то что автор на 8 месяцев не озаботился поправиться, это, конечно, не дело.
На 00:00 предпоследний вопрос , на 16:29 этот вопрос пропал из списка, и, конечно же, на него в видео не было ответа
Отлично рассказываешь. Смелее 😊
А вообще понятия не имею зачем джуну или мидлу в принципе знать что такое side table и хранятся ли weak и unowned где-то.
спрашивают на каждом собесе
@@ROCKY35638 могут спрашивать что угодно, суть в том зачем это спрашивать - непонятно.
👍
Красава, пушечный
1 вопрос! не скорее всего, а никогда. тк захватываются переменные, и у арс счетчики обнуляются в конце функции.. не прав? про гк тоже есть мнение, но промолчу
спасибо))
Доброго времени суток. Попробовал способ добавления в массив weak-переменных и они сразу в nil превратились. Так и должно быть?)
Ну они же никак не держатся в памяти другим способом, так что да
капитальный красавчик
unowned safe / unowned unsafe я вообще не понял что к чему, что-то крашит что-то не крашит, это же не ответ
смысл в том что unowned - это ссылка на ячейку в памяти.
ситуация: сильных ссылок нет, ячейка в памяти очищена. unowned safe обратиться к этой ячейки памяти и поймет что объекта там нет и крашнет прилу, а unowned unsafe обратиться к ячейки и, если эта ячейка уже содержит абсолютно "левый" объект то каки-то образом выдаст его. надеюсь я не наврал)