Подсчёт ссылок

[hinst]

Почему в FPC и Delphi сделали подсчёт ссылок для строк и динамических массивов, но не сделали для всего остального? Мне одному кажется, что это тупость какая-то? Хотели сделать процесс разработки более удобным, начали "крутить" и "недокрутили": явно освобождать память для строк и массивов теперь не надо, а для всего остального надо. Когда нибудь уже в конце концов сделают, чтобы можно было опционально включать подсчёт ссылок для своих типов? Тем более, для строк и массивов уже всё работает: если сделать динамический массив строк, то автоматически умрёт и массив указателей на строки, и сами строки тоже; так в чём же, #L^$%, проблема???

[runewalsh]

Интерфейсы.
/thread

(к сожалению, они дают дикий оверхед и в реалтайме почти неприменимы. Zero-overhead способов а-ля boost::shared_ptr нет и, по-видимому, не будет).

[hinst]

Интерфейсы.
...по-видимому, не будет).

а нужно чтобы были.

Добавлено спустя 6 минут 30 секунд:
пусть будут!

[Mirage]

Оверхед не такой дикий, чтобы не использовать нигде. 95% средней программы не критичны по производительности, так что там можно использовать интерфейсные ссылки. Я вот контейнер набросал, в который добавляю все временные сущности и он потом сам все удаляет. Без всяких try/finally. И финализирует, что важно. В Яве вот прочие ресурсы руками надо освобождать. Т.е. без finally никак.
Для критичных по производительности участков это неприемлемо, т.к. ссылки надо подсчитывать синхронизируя между тредами. В общем, блокировки светят. Да и в "zero-overhead boost::shared_ptr" слабо верится. "zero overhead" и "boost" вообще как-то странно рядом видеть.
По поводу "недокрутили" - Борланд (ну или те кто за них сейчас) уже ввел на мобильных платформах подсчет ссылок для классов тоже. Позже будет и для остальных платформ.
Опциональный подсчет ссылок малореален - будут проблемы на стыке. Да и второй корневой объект придется вводить.