buddenИванов Александр Александрович,
> А почему х там будет уничтожен?
То, что Вы посмотрели исходник, где всё написано, и не поняли, как раз и означает, что с Вас вполне уместно
> брать деньги за стажировку у нас
;)
> Посмотрел код, деструкторы в цепочку вызываются, а что будет если в среднем деструкторе ексепшен высыпится?
Вы правы в том, что поведение в этом случае отличается от try..finally.
Я думаю, эксепшн в деструкторе - это в любом случае нехорошо и такого быть не должно. Здесь последующие деструкторы не вызовутся, но я не думаю, что это большая беда по сравнению с самим фактом экспешена в деструкторе. Наверное, можно поменять логику так, чтобы исключения в деструкторе не препятствовали вызову последующих деструкторов. В моей практике пока эта особенность не вызывала проблем, т.к. эксепшн в деструкторе для меня означает плохой код, который нужно исправлять.
Хотя тут действительно есть о чём подумать...
Твой говнокод c помощью блокнота разобрать практически невозможно. Это короче не важно, важно другое. П моемому мнению, применять нестандартные решения в стандартных ситуациях, к добру не приведет. Да и зачем использовать подсчет ссылок на интерфейсы когда куда более естественным решением является try finally. Добавлять неясности в коде, ради того, чтобы уйти от одной вложенности - к надежности не приведет. Есть же правило, что достижение качества кода идет через снижение сложности. Мне куда понятней try finaly, нежели ковыряние в каком-то модуле на дредмет того, что делает OnStack.
А вто тут:
1.
2.
3.
4.
5.
6.
7.
8.
procedure testStackFrame;
var x:TExampleObject; fr:stackFr;
begin
fr:=mkStackFr;
x:=TExampleObject.Create;
onStack(x);
x.example;
end
mkStackFr - глобальная переменная? Тогда если например три подобных процедуры будут вызваны, освобождение первых двух будет когда только третья закончится? Или еще какие-то подводные камни я не учел?
