Легальный около Цэ++ шный холивар

Ага. Вот только деструкторы со сборкой не дружат, так что альтернативы нет...

Так чем тебе не нравится try-with-resources/using?

Цитата D_KEY @ 08.06.15, 20:03

Ага. Вот только деструкторы со сборкой не дружат, так что альтернативы нет...

Чисто теоретически - почему нельзя сделать вызов деструкторов обязательным при выходе из области видимости переменной? Вроде как должно быть удобно.

Цитата OpenGL @ 09.06.15, 06:28

Цитата D_KEY @ 08.06.15, 20:03

Ага. Вот только деструкторы со сборкой не дружат, так что альтернативы нет...

Чисто теоретически - почему нельзя сделать вызов деструкторов обязательным при выходе из области видимости переменной? Вроде как должно быть удобно.

Если у тебя нет объектов на стеке в языке, то это не так уж и просто.

Да ладно - компилятор знает всё о локальных объектах в момент компиляции. Что ещё нужно?

Цитата negram @ 09.06.15, 07:13

Да ладно - компилятор знает всё о локальных объектах в момент компиляции. Что ещё нужно?

Понять, что делать с кодом, который передаёт наш объект в какой-то метод, например. Сохраняется ли там ссылка на объект? Компилятор в общем случае это знать не может. Я уже не говорю о мультитредности. Не очень понятно, что делать и в более прозрачном случае, когда мы сохраняем объект в переменную охватывающей области видимости. Или в поле другого объекта.

Цитата D_KEY @ 08.06.15, 20:03

Так чем тебе не нравится try-with-resources/using?

Тем, что об этом должен знать пользовательский код? "Забыть вызвать деструктор" несколько сложнее. Опять же, в плюсах ты можешь в своём классе иметь данные, которые владеют ресурсами. При этом пользователю ничего дополнительно знать не надо. А со всякими try-with-resources, если внутри класса появляется ресурс, то надо править места, где класс используется.

Цитата D_KEY @ 09.06.15, 07:21

Понять, что делать с кодом, который передаёт наш объект в какой-то метод, например. Сохраняется ли там ссылка на объект? Компилятор в общем случае это знать не может.

Можно, например, со счётчиком ссылок это совместить.
Кстати, если в шарпе открыть файл/подключение/etc, и потерять ссылку на объект - финализатор даже по истечении времени не вызовется?

Цитата OpenGL @ 09.06.15, 09:27

Можно, например, со счётчиком ссылок это совместить.

ну это то же самое, что освобождать ресурс в финализаторе

Цитата DarkEld3r @ 09.06.15, 08:36

Цитата D_KEY @ 08.06.15, 20:03

Так чем тебе не нравится try-with-resources/using?

Тем, что об этом должен знать пользовательский код? "Забыть вызвать деструктор" несколько сложнее. Опять же, в плюсах ты можешь в своём классе иметь данные, которые владеют ресурсами. При этом пользователю ничего дополнительно знать не надо. А со всякими try-with-resources, если внутри класса появляется ресурс, то надо править места, где класс используется.

Забыть, условно, free - просто. Забыть открыть файл или получить другой ресурс сложнее
Не подумать о том, что ты открываешь ресурс тоже сложно.

Что касается полей в классе, то ты просто делаешь свой объект совместимым с тем же механизмом и возлагаешь ответственность на вызывающий код.ф

Добавлено 09.06.15, 09:59

Цитата OpenGL @ 09.06.15, 09:27

Цитата D_KEY @ 09.06.15, 07:21

Понять, что делать с кодом, который передаёт наш объект в какой-то метод, например. Сохраняется ли там ссылка на объект? Компилятор в общем случае это знать не может.

Можно, например, со счётчиком ссылок это совместить.

С каким счётчиком ссылок?

Добавлено 09.06.15, 10:34

Цитата wind @ 09.06.15, 09:33

Цитата OpenGL @ 09.06.15, 09:27

Можно, например, со счётчиком ссылок это совместить.

ну это то же самое, что освобождать ресурс в финализаторе

Нет. Финализатор когда вызовется, да и вызовется ли вообще - неизвестно. А счётчик ссылок даёт нам детерминированное время вызова. Как только 0, так сразу.

Цитата D_KEY @ 09.06.15, 09:58

С каким счётчиком ссылок?

С тем, который можно добавить при реализации этих деструкторов в языке

Цитата OpenGL @ 09.06.15, 10:36

Цитата D_KEY @ 09.06.15, 09:58

С каким счётчиком ссылок?

С тем, который можно добавить при реализации этих деструкторов в языке

И тут вылазит радость: сборка мусора быстрее, чем счётчики ссылок, которые ещё и циклами чреваты. Да, она имеет привычку "тормозить мир", а счётчики равномерно размазаны по программе, но они медленные.

Цитата D_KEY @ 09.06.15, 09:58

Что касается полей в классе, то ты просто делаешь свой объект совместимым с тем же механизмом и возлагаешь ответственность на вызывающий код.ф

Ну так я об этом и говорю. Вопрос был - "чем не нравятся try-with-resources/using". Ответ - тем, что пользовательскому коду надо знать про детали реализации. В плюсах, если я после рефакторинга добавил классу владение каким-либо ресурсом, пользовательский код менять не надо. А если у нас нет деструкторов, то безболезненно такие вещи не пройдут.

Цитата OpenGL @ 09.06.15, 10:36

Цитата D_KEY @ 09.06.15, 09:58

С каким счётчиком ссылок?

С тем, который можно добавить при реализации этих деструкторов в языке

Ага... Т.е. ссылки иногда будут просто ссылками(и тогда GC), а иногда для них ведётся подсчет ссылок? А типы это будут другие? Сможем наследоваться от класса с деструтором? Сможем породить от "обычного" класса класс с деструктором? Сможем сделать поле класса с деструктором? Сможем в классе с деструктором сделать поле "обычного" класса? Как будем бороться с циклическими ссылками? Разрешим ли сборщику удалять группы зацикленных объектов? Разрешим ли переключение из режима вызова деструктора в обычный стиль с using/with?

Добавлено 09.06.15, 17:25

Цитата DarkEld3r @ 09.06.15, 11:34

Вопрос был - "чем не нравятся try-with-resources/using". Ответ - тем, что пользовательскому коду надо знать про детали реализации.

Это не вопрос реализации... Может пример?

Сообщение отредактировано: D_KEY - 09.06.15, 17:25

Цитата D_KEY @ 09.06.15, 17:23

Это не вопрос реализации... Может пример?

Да как-то так:

var a = new SomeClass();
a.someMethod();

Потом в классе появляется поле владеющее ресурсом - в итоге код перестаёт быть корректным и надо его переделывать в:

using (var a = new SomeClass())
{
    a.someMethod();
}

При этом клиентам, вероятно, вообще не надо знать, что я там использую внутри. В С++, благодаря деструкторам, ничего менять не пришлось. Да, там тоже можно сделать new SomeClass и не позвать delete, но это уже другая проблема и с владением ресурсами она не связана. Да, я понимаю, что с ГЦ иначе и не сделать, но удобным оно от этого быть не начинает.

Сообщение отредактировано: DarkEld3r - 09.06.15, 18:46

Мне почему-то кажется, что тут в большинстве случаев можно изолировать использование ресурса внутри метода... Иначе бы SomeClass изначально воспринимался как ресурс.
Впрочем допускаю, что иногда это неудобно.