См?

И, конечно, в этих местах немного есть просидание

См?

GC

Сборщик мусора

А

А так скорость та же

Не идентична

Но +/- та же

+ как я понимаю, есть или будут, механизмы, позволяющие реализовать свой сборщик мусора

Вроде эта тема поднималась

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

Ну и освобождать ее

Если подавляющее большинство памяти использовать на стеке - то и СМ будет минимум работать

А я вот думал например для часто используемых объектов пул делать, как рекомендуют для того же юнити, стоит ли оно?

А я вот думал например для часто используемых объектов пул делать, как рекомендуют для того же юнити, стоит ли оно?

Сам так думаю делать)

А я вот думал например для часто используемых объектов пул делать, как рекомендуют для того же юнити, стоит ли оно?

Но там просто огород проблем

Например?

Смотри, у тебя объект имеет структуру:

{ int age string name }

Проблем нет

А если такой:

{ int age string name User[] children }

Что делать в этом случаи?

Как ты его будешь чистить?

Выходит я взял, поюзал объект и вернул его

А следующему уже попадется не пустой объект

Вариант: реализовывать метод очистки

В этом случае, имхо, куда проще его удалять и заново создавать

Можно чистить перед использованием

СМ тут особо не будет работать, так как ты его руками сам удалять будешь...

Можно чистить перед использованием

Да, но это уже не просто какой-то пул с методами: get() set()

Тут ты попадаешь на очистку объекта, которую должен реализовывать сам

Для каждого объекта

Ну можно сделать шаблонную функцию

А следовательно на реализацию какого-то интерфейса, согласен?

которая в большинстве случаев справится

Смотри

Она справится с первым случаем, а со вторым - нет

Т.к. ты не знаешь, эти объекты нужно возвращать в пул или просто удалить

Ну да

Но можно не интерфейс а атрибут

Вот и получается, что там не так просто

UDA?

UDA?

Да

А что делать с приватными полями?

а что с ними не так?

А как ты их будешь чистить снаружи?

Только внутри

Что нас снова приводит к реализации интерфейса

И снова мы туда что угодно уже не запихнем

Используя шаблонную магию вроде можно достучаться до приват полей

Если этот метод будет в этом объекте, а не снаружи

Там реально много проблем

И после я задумался, а стоит ли игра свечь?

Ну эт да

А я ща посмотрю, можно ли до приват полей достучаться

Может проще сделать что-то типа пула, но по факту обвертку над calloc?

А деструкторы всякие?

А они не вызываются разве?

Ну даже если они не вызываются, их же можно вызвать руками? или нет?

Я не в курсе

Я тоже

там обновлений компилятора не было?

Короче я пришел к выводу, что так будет проще

Но тесты и эксперементы еще не делал

НО!

Тут можно выделить реально не хилый кусок памяти

ERROR: S client not available

И использовать его

А если запариться

И добавить анализ и сохранение анализа

В какой-то файл для дальнейшего запуска

То там можно хранить среднее число тех или иных объектов

И, следовательно, на перед предугадывать, сколько же тебе может понадобиться объектов (памяти) под каждый тип объектов

Ну это так, к чему я пришел...

деструктор можно вызвать руками, через destroy. вроде так эта функция сейчас называется

деструктор можно вызвать руками, через destroy. вроде так эта функция сейчас называется

Во!

в ди нет же деструкторов как таковых

А после пометь занимаемую этим объектом память как не нужную...

~this — это финализатор, и при удалении объектов порядок вызова финализаторов не гарантирован

~this — это финализатор, и при удалении объектов порядок вызова финализаторов не гарантирован

Ну это то место, которое можно использовать как точку, когда объект более не используется

В контексте объекта

но порядок не гарантирован

Ну сейчас речь идет о работе над одним объектом

если руками не удалять объекты, а положиться на GC, то финализатор вызовется хз когда

и если в объекте ксть переменные, которые тоже являются объектами, в момент вызова финализатора они уже могут быть уничтожены

если руками не удалять объекты, а положиться на GC, то финализатор вызовется хз когда

Он вызовится перед удалением)

и если в объекте ксть переменные, которые тоже являются объектами, в момент вызова финализатора они уже могут быть уничтожены

Не думаю

а тут и думать нечего, так оно работает)

и если в объекте ксть переменные, которые тоже являются объектами, в момент вызова финализатора они уже могут быть уничтожены

В этом случае на объект еще есть ссылка, врядли он его удалит до того, как будет удален объект ссылающийся на него (исключение перекросные ссылки)

The garbage collector is not guaranteed to run the destructor for all unreferenced objects. Furthermore, the order in which the garbage collector calls destructors for unreferenced objects is not specified.

https://dlang.org/spec/class.html#destructors прямо на сайте

Сам же написал: "unreferenced objects"

А тут ссылка на него есть

да бляха, еще раз повторяю: порядок вызова ~this не гарантирован

Для объектов, на которых нет ссылок

Сам же цитату привел

А если ссылка есть - то гарантирован

Так, к приватным полям доступ получить легко

Пока ссылка на него не пропадет - не удалится