Иванов Александр Александрович,
> если очень хочется чтобы твой код смотрели, хоть модуль в порядок привел бы.
Я занят работой, и данный модуль мне в ней помогает. Меня он устраивает. Деструктор я поменял согласно комменатрию в примере, посмотрим, что будет. А так - я его приведу в порядок, когда перестанет устраивать. Мне умеренно хочется, чтобы Дельфи не умирал, поэтому я опубликовал этот код. Но не настолько, чтобы его менять, ведь я могу его сломать, а модуль ответственный и последствия могут быть серьёзными. "Оно работает? Да - не трогай его". Если хотите, можете в течение недели привести его в то, что Вы считаете порядком и, если мне понравится, я положу на Ваш телефон 500 рублей. Но я буду сильно придираться, учитывая Ваше плохое поведение. Категорически не рекомендуется менять стиль отступов.

> Но нет, надо строить из своего решения какую-то невероятно полезную вещь(коей она не является)
Полезной она являтся. Статистику использования я приводил. Раньше, каждый раз, когда мне надо было писать finally ... freeAndNil(x) ... end я ненавидел Дельфи, т.к. я знал, что в других языках без этого можно обойтись и знал, что нет никакой уважительной причины для отсутствия выделения объектов на стеке. Для разработчиков языка добавить такую поддержку - это раз плюнуть. Теперь я решил этот вопрос и спокойно работаю. Это польза, а Вы опять гоните и хочется ещё как-нибудь нелестно Вас назвать.

Скорее, эта фича не является настолько магической, как могло бы показаться. Ну и что? Полезной она от этого быть не перестаёт.

Esperito, что именно я упустил? Так уже можно? Я работаю в Delphi 2007 и не собираюсь ничего менять в обозримом будущем.

Gator, у меня достаточно долгий и успешный опыт обороны от прогресса.
Может, и придётся когда-нибудь, но думаю, что не скоро :)

EsperitoНа дженериках реализации scoped objects выглядят изящнее. Пример , реализация . Обрати внимание, Scoped - это record.
Но стоит ли ради этого жертвовать производительностью и натыкаться на грабли?
Возможно, изящнее, но в моём языке их нет. Производительностью жертвовать ради выразительности стоит почти всегда, а грабель я тут особых не вижу.

Esperito, вывод? Я данную проблему для себя давно решил без дженериков, т.е. мотива переходить на что-то у меня нет. Мой код - это не "изыскания", как Вы изволили выразится, а рабочий инструмент, который я постоянно использую (статистику применения см. выше в теме). Буду и дальше пользоваться тем, что написал. Абсолютно уверен, что не все спешат перейти на каждую новую версию Delphi или других программ, которые только появляются в природе. Найдутся люди, которым мой код пригодится. Кому не нравится оформление - могут взять идею и сделать своё такое же. Если кому-то не пригодится - что ж, значит не пригодится, на вкус и цвет товарищей нет.

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


Эти функции позволяют однородно обращаться к уже существующим классам, которые стали не родственными из-за ограничений наследования в Дельфи. Например, к классам VCL. Да, это медленное обращение, но это - 0.1% всех обращений к объектам, а в Питоне 100% обращений к объектам делаются так, и всё равно на Питоне пишут полезные программы. Может быть, то же самое можно сделать лучше с дженериками, но и без дженериков тоже можно.

Дженериков я наелся, когда пришлось программировать на С++. Я безконечно далёк от того, чтобы ими восхищаться. В С++ они порождают не меньше проблем, чем решают. Возможно, в Дельфи они сделаны менее криво, чем в С++, но этот вопрос для меня не имеет пока даже академического интереса, потому что мне интересен только один вид препроцессора - это defmacro.

> OnStack - я так понимаю имеется в виду FILO.
Удивительно, конечно, что у народа возникают трудности с элементарными вещами, но FILO, или скорее LIFO - это не просто так,это фундаментальная особенность очень многих явлений жизни.

Деньги в кошельке,кошелёк в кармане. Смерть в игле, игла в яйце, яйцо в утке, и т.п. Компонент принадлежит форме, форма принадлежит приложению. Сначала подключись к серверу, потом открой запрос. Порядок уничтожения определяется порядком вложенности.

Соответственно, размещение именно на стеке это паттерн, к-рый зачастую делает алгоритм ясным.

> Убрать try finally, который является стандартом
Не стоит забывать, что Object Pascal вырос просто из Паскаля, к-рый является учебным языком, не самым удачным. То ли у Вирта не хватило ума, то ли сработали какие-то ограничения (по времени,бюджету, числу страниц стандарта). Выучите лисп, бейсик, bash и С++ для расширения кругозора, тогда станет ясно, что почти во всех языках не хватает каких-то важных концепций и их приходится реализовывать с помощью костылей. Лучше всего, конечно же, выучить лисп, потому что в нём больше всего концепций, незнакомых современным программистам и потому что в нём наиболее мощные способы создания костылей. Хотя потихонечку его и разворовывают, например, лямбда-функции, которые в лиспе были ещё в 80-х годах, (если не в 60-х) наконец-то появились и в С#, и в Дельфи, если мне память не изменяет. Я написал данный код, основываясь на практике работы в лиспе и используя концепции лиспа. Например, bindingVariable - это эмуляция понятия special variable лиспа, до которой дизайнеры "современных" языков, может быть, ещё не додумались, хотя она очень естественна.

Короче говоря, для Вас стандарт - это, может быть, что-то святое, а я отношусь к нему лишь как к инструменту. Слава Богу, я веду свой проект сам и могу позволить себе роскошь устанавливать свои правила кодирования.

> По-моемому, проще функцию назвать типа как в С# - "В сборщик мусора".
Это разные понятия. При сборке мусора момент уничтожения объекта неизвестен. Для типонебезопасных языков, в к-рых легко испортить память и к к-рым относится и Delphi, это слишком опасно. Размещение "на стеке" наиболее безопасно, т.к. момент уничтожения объекта точно определён. Более мощными и более опасными методами (подсчёт ссылок и сборка мусора в собственном смысле слова) в таких языках нужно пользоваться только тогда, когда они действительно необходимы. Ближайший аналог того, что я написал - это именно размещение на стеке, отсюда и название.

> но и для обеспечения логической целостности
Уничтожение объектов тоже может служить логической целостности, на этом основано finallydoo и объекты-стражи (guard). Всё это у меня реализовано, не считая того, что экспешен в "финализаторе" в текущей версии сломает механизм.

Vladimir Baskakovесли ограничивать "время жизни" пределами ф-ции - да, все хорошо. Если как в плюсах например иметь локальные переменные внутри блоков..... то опять - try - finally ?
Да, есть такая неприятность. Два варианта:
1. try-finally и вторая переменная fr2, к-рая на finally явно присваивается unassigned.
2. локальная процедура и в ней локальная переменная fr. например ограничивать время жизни объекта одной итерацией цикла?
Если количество итераций не слишком велико и деструкто объекта просто освобождает память, я не парюсь
и размещаю объекты для всех итераций "на стеке",примерно так:

В итоге будет размещено N объектов и все они будут уничтожены при закрытии fr.
Если же объект является хранителем чего-то и его деструктор нужен не только для освобождения памяти,
но и является частью логики приложения, то остаётся try-finally или оформить тело цикла в виде процедуры.
_Vasilisk_...многопоточное приложение...Не помню, чтобы я это тестировал, но, по замыслу, должно работать. Переменная, содержащая текущий кадр стека - threadvar, не вижу других граблей.

EsperitoP.S. То, что у вас реализовано, - это не сборка мусора.
Я разве это утверждал? Перед тем, как я начал тему, мне показалось, что мне нужна для одного дела сборка мусора, но я уже давно без неё обошёлся и даже забыл повод. А всё обсуждение stackutil - это офтоп, вообще-то.

Esperito, ну вообще, вопрос, который я поставил в своём первом комменте, по-моему, так и остался без ответа.
Касаемо моего кода, stackutil, видимо, нужно сделать более развёрнутый набор примеров, тестовые проекты, протестировать потокобезопасность, но у меня нет времени этим заниматься и не скоро появится.