если присвоены переменной? Точнее говоря, переменная гарантированно доживёт до конца?
с managed рекордами дел не имел, но энивей, гарантии неоткуда взяться - оптимизатор очевидно имеет право "прибивать" после ласт использования. Надо полностью "оборачивать" и уже через это работать.
Во что оборачивать?
в некий самописный TSmartPtr, на основе манажед рекорда/интерфейса c проперти Value которое и будет содержать ссылку на обект, и через него и работать полностью
Почему проперти Value гарантирует жизнь до конца скоупа?
Не проперти, а то что мы создаем некую прослойку и работаем ток через нее, и поскольку работаем ток через нее, то нет возможности того что прослойка откиснет раньше, прибив и объект, чем объект который она "дежит" будет использован ласт раз
Так, причём тут объект. Речь про defer, который никакого объекта не содержит, а только лямбду.
вот примеры каке-то оберток аля смарт поитнер https://blog.grijjy.com/2020/08/12/custom-managed-records-for-smart-pointers/
мы возвращаем интерфейсную ссылку и никуда ее не сохраняем, почему компилятор в принципе ее должен "живой" до конца держать то? был бы оптимизатор попроворнее - заинлайнил бы создание и прибивание объекта сразу, или даже выкидывание вообще всего кода
А если даже сохраняем интересную ссылку, но не используем её, может ли компилятор грохнуть её заранее, ДО конца процедуры??
Да, гарантий что не грохнет никаких в доках нет. В RSP-30050 (в qc embarcadero вбейте в поиск) как раз пример такого «грохания». Из текущего скоупа ПОКА не грохает, но гарантий 0.
Спасибо, гляну (наверное 😁). Но со смарт поинтерами как ты понятно. Интерфейс/запись не уничтожается, т.к. где-то дальше по коду ты его юзаешь. А как реализовать аналог RAII, чтобы оно не грохнулось раньше времени?
в каком именно коде, пример бы
Обсуждают сегодня