Здравствуйте, _NN_, Вы писали:
_NN>Ну так поэтому в Dispose всегда вызывается GC.SuppressFinalize(this) . _NN>И тогда для этого объекта финализатор не будет вызываться.
это то да но выходит я верну из этой функции список ссылок на мертвые объекты для которых уже вызвались dispose и финализаторы) хотя раз ссылки в списке на них есть GC все еще не будет освобождать из под них память но такие объекы уже ни на что не годны так как освободили все свои ресурсы
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>Здравствуйте, _NN_, Вы писали:
_NN>>Ну так поэтому в Dispose всегда вызывается GC.SuppressFinalize(this) . _NN>>И тогда для этого объекта финализатор не будет вызываться.
J>это то да но выходит я верну из этой функции список ссылок на мертвые объекты для которых уже вызвались dispose и финализаторы) хотя раз ссылки в списке на них есть GC все еще не будет освобождать из под них память но такие объекы уже ни на что не годны так как освободили все свои ресурсы
Почему финализаторы вызваны ? Если не объект есть ссылка , он не будет вызван.
Просто не вызывайте Dispose , проблема то в чем ?
В C++/CLI это означает создавать через gcnew, а не просто "A a;" .
Еще раз возьмем аналог, просто класс с методами Start, Stop.
Что будет если я вызову Stop и верну объект ?
Тут либо нужно не возвращать такой объект , либо объект должен быть готов , что Stop можно вызвать несколько раз.
Вам нужно решить что вы хотите делать.
Здравствуйте, _NN_, Вы писали:
_NN>Почему финализаторы вызваны ? Если не объект есть ссылка , он не будет вызван. _NN>Просто не вызывайте Dispose , проблема то в чем ? _NN>В C++/CLI это означает создавать через gcnew, а не просто "A a;" .
так я то говорю только про случай со стек семантикой как в моем примере
понятно что если создавать объекты через gcnew то все будет хорошо
мне именно было интересно когда передается "наверх" адрес объекта со стек семантикой
для которого при выходе из скопа выполнятся dispose/финализатор
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>мне именно было интересно когда передается "наверх" адрес объекта со стек семантикой J>для которого при выходе из скопа выполнятся dispose/финализатор
Очевидно , что если объект выходит наружу из функции , так делать не стоит
Здравствуйте, _NN_, Вы писали:
J>>для которого при выходе из скопа выполнятся dispose/финализатор _NN>Очевидно , что если объект выходит наружу из функции , так делать не стоит
вот наконец то мы пришли к пониманию но в моем случае когда у меня нет ни dispose метода
ни финализатора это же абсолютно безопасно ? ведь все равно он будет в памяти висеть пока
у меня в списке ссылки на него
Здравствуйте, _NN_, Вы писали:
_NN>Если объект кто-то держит, то его финализатор не вызовется просто так. _NN>Если вызван был Dispose , который освободил ресурсы, то тут ничего не поделать. _NN>Это как вызвать метод Stop два раза, что по вашему должно произойти ? _NN>Обычно в таких случаях кидается System.ObjectDisposedException .
To help ensure that resources are always cleaned up appropriately, a Dispose method should be callable multiple times without throwing an exception.
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>Здравствуйте, samius, Вы писали:
S>>Будет
S>>
S>>Calling the destructor will suppress (with SuppressFinalize) finalization of the object. If the destructor is not called, your type's finalizer will eventually be called by the garbage collector.
J>будет только если не будет вызван деструктор (dispose) который сам не вызовет финализер а если будет и он сам не вызвал финализер то такой финализер уже никогда не вызовется
GC не оперирует понятиями был ли вызван деструктор (dispose) или не был. GC смотрит на список финализации и принимает решение о вызове финалайза. А тот уже безусловно зовет финализатор.
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>Здравствуйте, _NN_, Вы писали:
_NN>>Почему финализаторы вызваны ? Если не объект есть ссылка , он не будет вызван. _NN>>Просто не вызывайте Dispose , проблема то в чем ? _NN>>В C++/CLI это означает создавать через gcnew, а не просто "A a;" .
J>так я то говорю только про случай со стек семантикой как в моем примере J>понятно что если создавать объекты через gcnew то все будет хорошо J>мне именно было интересно когда передается "наверх" адрес объекта со стек семантикой J>для которого при выходе из скопа выполнятся dispose/финализатор
Когда вы используете стек-семантику, вы обещаете компилятору не использовать объект за пределами скопа. А компилятор отвечает за код, способствующий детерминированному вызову деструктора вне зависимости от того, сколько ссылок на объект при этом уйдет "наверх". Компилятор их не считает.
Здравствуйте, samius, Вы писали:
S>Когда вы используете стек-семантику, вы обещаете компилятору не использовать объект за пределами скопа. А компилятор отвечает за код, способствующий детерминированному вызову деструктора вне зависимости от того, сколько ссылок на объект при этом уйдет "наверх". Компилятор их не считает.
в общем случае да но в моем примере объект в куче и живой никаких dispose для него не выполняется почему я не могу передать ссылку на него наверх ?
Здравствуйте, samius, Вы писали:
S>GC не оперирует понятиями был ли вызван деструктор (dispose) или не был. GC смотрит на список финализации и принимает решение о вызове финалайза. А тот уже безусловно зовет финализатор.
да но dispose делает supressfinalize исключая тем самым финализацию для этого объекта
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>Здравствуйте, samius, Вы писали:
J>в общем случае да но в моем примере объект в куче и живой никаких dispose для него не выполняется почему я не могу передать ссылку на него наверх ?
Можете, только зачем использовать стек-семантику?
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>Здравствуйте, samius, Вы писали:
S>>GC не оперирует понятиями был ли вызван деструктор (dispose) или не был. GC смотрит на список финализации и принимает решение о вызове финалайза. А тот уже безусловно зовет финализатор.
J>да но dispose делает supressfinalize исключая тем самым финализацию для этого объекта
Это в общем случае верно лишь для объектов, написанных на C++/CLI, где явно не нужно вызывать SuppressFinalize и код его вызова генерит компилятор. В остальных языках — это вопрос выполнения соглашения о реализации паттерна IDisposable.
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>да собственно незачем просто было интересно можно ли так делать
С точки зрения результата компиляции — можно.
С точки зрения процесса разработки — не стоит. Можно от главного архитектора получить линейкой по пальцам.
Потому что вы таким образом раскладываете грабли — сегодня в классе вашего объекта нет диспоуза, а завтра его кто-то закоммитит, и приложение начнёт падать в неожиданном месте.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
но выходит я верну из этой функции список ссылок на мертвые объекты для которых уже вызвались dispose и финализаторы) хотя раз ссылки в списке на них есть GC все еще не будет освобождать из под них память но такие объекы уже ни на что не годны так как освободили все свои ресурсы
