это явно написано в пункте 6 по ссылке, которую я привел

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

Покажи пример. Так не верю

This rule does not apply to auto objects or objects destructed with destroy, as the destructor is not being run by the garbage collector, meaning all references are valid.

Тоже цитата с той ссылки

А мы именно о этой ситуации и говорим

Прочитай выше

я про то и говорил, что если полагаться на GC, то можно огрести проблем

если удалять объекты руками, то их не будет)

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

+ по той же ссылке. что ты привел: Destructors

Пункт 15.10

Путаешься в показаниях)

это финализатор по факту

А в чем отличие?

который при destroy будет как бы деструктором

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

Поделись как?

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

при этом сборщик мусора не гарантирует порядок вызова финализаторов

Так в чем отличие от деструктора?

https://ru.wikipedia.org/wiki/Деструктор

Дестру́ктор — специальный метод класса, служащий для деинициализации объекта (например освобождения памяти).

In object-oriented programming, a destructor (dtor) is a method which is automatically invoked when the object is destroyed

https://en.wikipedia.org/wiki/Destructor_(computer_programming)

Если ты для себя обрисовал какую-то разницу, хорошо, я не спорю. Но даже на официальном сайте (в документации) написано - это деструктор

И я с ними согласен

Это хэндлер (метод), который вызывается перед тем, как объект будет безвозвратно удален

и в этом методе, в контексте D и большинства других GC-языков, в общем случае небезопасно обращаться к внутренним структурам даных, которые управляются GC

Если объекты создавать что-то типа такого: Pool!MyClass(many, param, init) То можно сделать красивую обертку...

и в этом методе, в контексте D и большинства других GC-языков, в общем случае небезопасно обращаться к внутренним структурам даных, которые управляются GC

Это везде так

везде, где есть GC, да, поэтому обычно такие штуки называют финализаторами, но мы можем называть деструкторами)

Метод служит для того, чтобы специфично очистить объект, а не обращаться куда-то за чем-то

везде, где есть GC, да, поэтому обычно такие штуки называют финализаторами, но мы можем называть деструкторами)

С чего вдруг?

с чего вдруг что?

Не деструктор, а какой-то финализатор

https://ru.wikipedia.org/wiki/%D0%A4%D0%B8%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%82%D0%BE%D1%80

ну принято так

У меня один вопрос: где в куске кода, который я кидал выше, может вызываться конструктор?

А, я как обычно забыл, что приватность по модулю

ыгы

Но можно сделать миксин!

типа

struct Foo { ... } mixin Poolable!Foo;

Да, снова мы приходим к тому, что при описании класса, его нужно специфично описывать

Ну да

Но это проще, чем самому реализовывать

Но это проще, чем самому реализовывать

И тут возникает вопрос: стоит ли игра свечь?

https://ru.wikipedia.org/wiki/%D0%A4%D0%B8%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%82%D0%BE%D1%80

Прочел и все равно не понял разницу от деструктора

очень жаль)

Когда тогда он вызывается с твоей т. зрения?

Деструктор

А там размыто написанна разница

Если так рассуждать, то деструктор можно создать только самому

А не при помощи СМ

деструктор — это понятие из области ручного управления памятью

Хм...

Как частный случай финализатора...

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

т.е. вот делаешь ты в C++ delete, вызывается деструктор

или в D выходит структура из области видимости, для нее вызывается деструктор

делаешь destroy, вызывается...

делаешь destroy, вызывается...

Это и есть, ручное...

destroy вообще странная штука, она вызывает финализатор и обнуляет память объекта, но эта область остается зарезервированной в GC

destroy вообще странная штука, она вызывает финализатор и обнуляет память объекта, но эта область остается зарезервированной в GC

Ну это понятное дело

да, это ручное. понятие деструктора и финализатора в D размыто

Слишком дорого память гонять туда-сюда, да еще и такими маленькими кусочками

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

Да, согласен. Значит финализатор.

ERROR: S client not available

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

Не спорим, а дискутируем

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

natum fuerit quaestionis veritatem

"в споре рождается истина"

ну просто в D, если не гарантировать, что для объекта будет вызван destroy, нужно очень аккуратно использовать ~this

так же как и в шарпе

как и в любом другом известном мне GC языке)

Уже ведь куча стратегий реализована в std.experimental.allocator. имхо там 90% случаев покрыто

Ну такое

Я предпочитаю использовать https://dlang.org/library/core/stdc/stdlib/malloc.html

Чем "std.experimental"

А если что - потом и поменять не проблема

Там просто уже много всего. И достаточно экзотические варианты есть

Ну...

Мне стремно использовать такой неймспейс)

Делаю небольшой тест

Замер вызова функций из *.SO

и простой ф-ции

./main 1 1000000000 3 secs, 748 ms, and 540 μs dl= 1000000000 2 secs, 361 ms, and 36 μs m1= 1000000000 2 secs, 307 ms, and 932 μs m2= 1000000000

первая строка - это вызов ф-ции из *.so

2я строка - это extern (C) uint m1()

3я строка - uint m2()

последнее число - количество вызовов

Это 1 миллиард вызовов

3 ms and 856 μs dl= 1000000 2 ms and 765 μs m1= 1000000 3 ms and 13 μs m2= 1000000

1 лям

В принципи, не так уж и много наклодных расходов

10 μs dl= 1000 3 μs m1= 1000 3 μs m2= 1000

6 μs dl= 1000 3 μs m1= 1000 3 μs m2= 1000

Согласен, тесты не честные, но все же...

Буду пробовать на *.so-ки выносить функционал

Народ, а асинхронный код может работать в несколько потоков?

Конечно