Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.219.14.63] |
|
Страницы: (15) « Первая ... 9 10 [11] 12 13 ... Последняя » все ( Перейти к последнему сообщению ) |
Сообщ.
#151
,
|
|
|
Ага. Вот только деструкторы со сборкой не дружат, так что альтернативы нет...
Так чем тебе не нравится try-with-resources/using? |
Сообщ.
#152
,
|
|
|
Цитата D_KEY @ Ага. Вот только деструкторы со сборкой не дружат, так что альтернативы нет... Чисто теоретически - почему нельзя сделать вызов деструкторов обязательным при выходе из области видимости переменной? Вроде как должно быть удобно. |
Сообщ.
#153
,
|
|
|
Цитата OpenGL @ Цитата D_KEY @ Ага. Вот только деструкторы со сборкой не дружат, так что альтернативы нет... Чисто теоретически - почему нельзя сделать вызов деструкторов обязательным при выходе из области видимости переменной? Вроде как должно быть удобно. Если у тебя нет объектов на стеке в языке, то это не так уж и просто. |
Сообщ.
#154
,
|
|
|
Да ладно - компилятор знает всё о локальных объектах в момент компиляции. Что ещё нужно?
|
Сообщ.
#155
,
|
|
|
Цитата negram @ Да ладно - компилятор знает всё о локальных объектах в момент компиляции. Что ещё нужно? Понять, что делать с кодом, который передаёт наш объект в какой-то метод, например. Сохраняется ли там ссылка на объект? Компилятор в общем случае это знать не может. Я уже не говорю о мультитредности. Не очень понятно, что делать и в более прозрачном случае, когда мы сохраняем объект в переменную охватывающей области видимости. Или в поле другого объекта. |
Сообщ.
#156
,
|
|
|
Цитата D_KEY @ Так чем тебе не нравится try-with-resources/using? Тем, что об этом должен знать пользовательский код? "Забыть вызвать деструктор" несколько сложнее. Опять же, в плюсах ты можешь в своём классе иметь данные, которые владеют ресурсами. При этом пользователю ничего дополнительно знать не надо. А со всякими try-with-resources, если внутри класса появляется ресурс, то надо править места, где класс используется. |
Сообщ.
#157
,
|
|
|
Цитата D_KEY @ Понять, что делать с кодом, который передаёт наш объект в какой-то метод, например. Сохраняется ли там ссылка на объект? Компилятор в общем случае это знать не может. Можно, например, со счётчиком ссылок это совместить. Кстати, если в шарпе открыть файл/подключение/etc, и потерять ссылку на объект - финализатор даже по истечении времени не вызовется? |
Сообщ.
#158
,
|
|
|
Цитата OpenGL @ Можно, например, со счётчиком ссылок это совместить. ну это то же самое, что освобождать ресурс в финализаторе |
Сообщ.
#159
,
|
|
|
Цитата DarkEld3r @ Цитата D_KEY @ Так чем тебе не нравится try-with-resources/using? Тем, что об этом должен знать пользовательский код? "Забыть вызвать деструктор" несколько сложнее. Опять же, в плюсах ты можешь в своём классе иметь данные, которые владеют ресурсами. При этом пользователю ничего дополнительно знать не надо. А со всякими try-with-resources, если внутри класса появляется ресурс, то надо править места, где класс используется. Забыть, условно, free - просто. Забыть открыть файл или получить другой ресурс сложнее Не подумать о том, что ты открываешь ресурс тоже сложно. Что касается полей в классе, то ты просто делаешь свой объект совместимым с тем же механизмом и возлагаешь ответственность на вызывающий код.ф Добавлено Цитата OpenGL @ Цитата D_KEY @ Понять, что делать с кодом, который передаёт наш объект в какой-то метод, например. Сохраняется ли там ссылка на объект? Компилятор в общем случае это знать не может. Можно, например, со счётчиком ссылок это совместить. С каким счётчиком ссылок? Добавлено Цитата wind @ Цитата OpenGL @ Можно, например, со счётчиком ссылок это совместить. ну это то же самое, что освобождать ресурс в финализаторе Нет. Финализатор когда вызовется, да и вызовется ли вообще - неизвестно. А счётчик ссылок даёт нам детерминированное время вызова. Как только 0, так сразу. |
Сообщ.
#160
,
|
|
|
Цитата D_KEY @ С каким счётчиком ссылок? С тем, который можно добавить при реализации этих деструкторов в языке |
Сообщ.
#161
,
|
|
|
Цитата OpenGL @ Цитата D_KEY @ С каким счётчиком ссылок? С тем, который можно добавить при реализации этих деструкторов в языке И тут вылазит радость: сборка мусора быстрее, чем счётчики ссылок, которые ещё и циклами чреваты. Да, она имеет привычку "тормозить мир", а счётчики равномерно размазаны по программе, но они медленные. |
Сообщ.
#162
,
|
|
|
Цитата D_KEY @ Что касается полей в классе, то ты просто делаешь свой объект совместимым с тем же механизмом и возлагаешь ответственность на вызывающий код.ф Ну так я об этом и говорю. Вопрос был - "чем не нравятся try-with-resources/using". Ответ - тем, что пользовательскому коду надо знать про детали реализации. В плюсах, если я после рефакторинга добавил классу владение каким-либо ресурсом, пользовательский код менять не надо. А если у нас нет деструкторов, то безболезненно такие вещи не пройдут. |
Сообщ.
#163
,
|
|
|
Цитата OpenGL @ Цитата D_KEY @ С каким счётчиком ссылок? С тем, который можно добавить при реализации этих деструкторов в языке Ага... Т.е. ссылки иногда будут просто ссылками(и тогда GC), а иногда для них ведётся подсчет ссылок? А типы это будут другие? Сможем наследоваться от класса с деструтором? Сможем породить от "обычного" класса класс с деструктором? Сможем сделать поле класса с деструктором? Сможем в классе с деструктором сделать поле "обычного" класса? Как будем бороться с циклическими ссылками? Разрешим ли сборщику удалять группы зацикленных объектов? Разрешим ли переключение из режима вызова деструктора в обычный стиль с using/with? Добавлено Цитата DarkEld3r @ Вопрос был - "чем не нравятся try-with-resources/using". Ответ - тем, что пользовательскому коду надо знать про детали реализации. Это не вопрос реализации... Может пример? |
Сообщ.
#164
,
|
|
|
Цитата D_KEY @ Это не вопрос реализации... Может пример? Да как-то так: var a = new SomeClass(); a.someMethod(); Потом в классе появляется поле владеющее ресурсом - в итоге код перестаёт быть корректным и надо его переделывать в: using (var a = new SomeClass()) { a.someMethod(); } При этом клиентам, вероятно, вообще не надо знать, что я там использую внутри. В С++, благодаря деструкторам, ничего менять не пришлось. Да, там тоже можно сделать new SomeClass и не позвать delete, но это уже другая проблема и с владением ресурсами она не связана. Да, я понимаю, что с ГЦ иначе и не сделать, но удобным оно от этого быть не начинает. |
Сообщ.
#165
,
|
|
|
Мне почему-то кажется, что тут в большинстве случаев можно изолировать использование ресурса внутри метода... Иначе бы SomeClass изначально воспринимался как ресурс.
Впрочем допускаю, что иногда это неудобно. |