Сообщение Re[4]: Жизнь после Dispose (.net) от 09.07.2015 1:28
Изменено 09.07.2015 6:08 ylem
Полностью поддерживаю все вышесказанное и не поддерживаю гайдлайны в той строчке.
ST>состояние объекта изменяется сразу же после вызова метода, а не когда-то позже.
Тут можно "выкрутиться" такими способами:
1. состояние объекта меняется сразу после _окончания_ вызова, т.е. при вызове Dispose ставим разрушение в очередь после уже запланированных GetNext().
2. считаем, что время относительно (для разных потоков, пока не сделали какую-нибудь синхронизацию нет понятия "одновременно"), и тогда при (1) не нужно даже блокировать вызов Dispose. Поток, который вызвал Dispose, не сможет различить ситуации изменилось ли состояние объекта "сразу" или "когда-то позже" (вызов GetNext вернет false ну или кинет исключение).
А по гайдлайнам, кстати, после вызова Dispose вообще не положено узнавать состояние объекта.
ST>состояние объекта изменяется сразу же после вызова метода, а не когда-то позже.
Тут можно "выкрутиться" такими способами:
1. состояние объекта меняется сразу после _окончания_ вызова, т.е. при вызове Dispose ставим разрушение в очередь после уже запланированных GetNext().
2. считаем, что время относительно (для разных потоков, пока не сделали какую-нибудь синхронизацию нет понятия "одновременно"), и тогда при (1) не нужно даже блокировать вызов Dispose. Поток, который вызвал Dispose, не сможет различить ситуации изменилось ли состояние объекта "сразу" или "когда-то позже" (вызов GetNext вернет false ну или кинет исключение).
А по гайдлайнам, кстати, после вызова Dispose вообще не положено узнавать состояние объекта.
Re[4]: Жизнь после Dispose (.net)
Полностью поддерживаю все вышесказанное и не поддерживаю гайдлайны в той строчке.
ST>состояние объекта изменяется сразу же после вызова метода, а не когда-то позже.
Тут можно "выкрутиться" такими способами:
1. состояние объекта меняется сразу после _окончания_ вызова, т.е. при вызове Dispose ставим разрушение в очередь после уже запланированных GetNext().
2. считаем, что время относительно (для разных потоков, пока не сделали какую-нибудь синхронизацию нет понятия "одновременно"), и тогда при (1) не нужно даже блокировать вызов Dispose. Поток, который вызвал Dispose, не сможет различить ситуации изменилось ли состояние объекта "сразу" или "когда-то позже" (заблокируется уже вызов GetNext и вернет false ну или кинет исключение по окончании своей работы).
А по гайдлайнам, кстати, после вызова Dispose вообще не положено узнавать состояние объекта.
ST>состояние объекта изменяется сразу же после вызова метода, а не когда-то позже.
Тут можно "выкрутиться" такими способами:
1. состояние объекта меняется сразу после _окончания_ вызова, т.е. при вызове Dispose ставим разрушение в очередь после уже запланированных GetNext().
2. считаем, что время относительно (для разных потоков, пока не сделали какую-нибудь синхронизацию нет понятия "одновременно"), и тогда при (1) не нужно даже блокировать вызов Dispose. Поток, который вызвал Dispose, не сможет различить ситуации изменилось ли состояние объекта "сразу" или "когда-то позже" (заблокируется уже вызов GetNext и вернет false ну или кинет исключение по окончании своей работы).
А по гайдлайнам, кстати, после вызова Dispose вообще не положено узнавать состояние объекта.