Привет всем.

С удивлением обнаружил, что хоть Microsoft и постарались — ввели конструкторы даже в те языки, что их не поддерживали, они убрали деструкторы. Предлагаемая взамен комбинация Finalize/Dispose не гарантирует того, что гарантировал автоматический деструктор C++. Все хорошо, если освобождаемые ресурсы в памяти, то есть подвласны сборщику мусора. Но бывают ситуации когда это не так:
Есть класс, представляющий из себя нечто вроде моникера для файлов лежащих далеко в "медленной" сети. При первой загрузке файла, он закачивает его и сохраняет локально в кеш. В деструкторе локальная копия убивается. А где его убивать сейчас?

Андрей

Здравствуйте Андрей Швыдкый, Вы писали:

АШ>Привет всем.

АШ>С удивлением обнаружил, что хоть Microsoft и постарались — ввели конструкторы даже в те языки, что их не поддерживали, они убрали деструкторы. Предлагаемая взамен комбинация Finalize/Dispose не гарантирует того, что гарантировал автоматический деструктор C++. Все хорошо, если освобождаемые ресурсы в памяти, то есть подвласны сборщику мусора. Но бывают ситуации когда это не так:
АШ>Есть класс, представляющий из себя нечто вроде моникера для файлов лежащих далеко в "медленной" сети. При первой загрузке файла, он закачивает его и сохраняет локально в кеш. В деструкторе локальная копия убивается. А где его убивать сейчас?

АШ>Андрей

А почему бы не сделать метод close() и вызывать его вместо деструктора ? :)

Здравствуйте Аноним, Вы писали:

А>Здравствуйте Андрей Швыдкый, Вы писали:

АШ>>Привет всем.

АШ>>С удивлением обнаружил, что хоть Microsoft и постарались — ввели конструкторы даже в те языки, что их не поддерживали, они убрали деструкторы. Предлагаемая взамен комбинация Finalize/Dispose не гарантирует того, что гарантировал автоматический деструктор C++. Все хорошо, если освобождаемые ресурсы в памяти, то есть подвласны сборщику мусора. Но бывают ситуации когда это не так:
АШ>>Есть класс, представляющий из себя нечто вроде моникера для файлов лежащих далеко в "медленной" сети. При первой загрузке файла, он закачивает его и сохраняет локально в кеш. В деструкторе локальная копия убивается. А где его убивать сейчас?

АШ>>Андрей

А>А почему бы не сделать метод close() и вызывать его вместо деструктора ?

Это решение "в лоб". (Кстати вышеупомятутый Dispose так и предлагают использовать). Кто гарантирует что я смогу вызвать этот Close? В случае исключительных ситуаций выполнение кода может быть не совсем детерминировано. Это ж что ж возвращаемся в прошлый век?
"Контролируй друже то шо пышеш, бо реализовать аналог smart pointer-а теперь низя"

Андрей

Здравствуйте Андрей Швыдкый, Вы писали:

АШ>Здравствуйте Аноним, Вы писали:

А>>Здравствуйте Андрей Швыдкый, Вы писали:

АШ>>>Привет всем.

АШ>>>С удивлением обнаружил, что хоть Microsoft и постарались — ввели конструкторы даже в те языки, что их не поддерживали, они убрали деструкторы. Предлагаемая взамен комбинация Finalize/Dispose не гарантирует того, что гарантировал автоматический деструктор C++. Все хорошо, если освобождаемые ресурсы в памяти, то есть подвласны сборщику мусора. Но бывают ситуации когда это не так:
АШ>>>Есть класс, представляющий из себя нечто вроде моникера для файлов лежащих далеко в "медленной" сети. При первой загрузке файла, он закачивает его и сохраняет локально в кеш. В деструкторе локальная копия убивается. А где его убивать сейчас?

АШ>>>Андрей

А>>А почему бы не сделать метод close() и вызывать его вместо деструктора ? :)

АШ>Это решение "в лоб". (Кстати вышеупомятутый Dispose так и предлагают использовать). Кто гарантирует что я смогу вызвать этот Close? :???: В случае исключительных ситуаций выполнение кода может быть не совсем детерминировано. Это ж что ж возвращаемся в прошлый век?
АШ>"Контролируй друже то шо пышеш, бо реализовать аналог smart pointer-а теперь низя"

АШ>Андрей

Андрей, я в .Net не силен, но раз уж микрософт столько содрала с Java, то наверняка есть и аналог try{}finally{}

Здравствуйте Андрей Швыдкый, Вы писали:

АШ>Есть класс, представляющий из себя нечто вроде моникера для файлов лежащих далеко в "медленной" сети. При первой загрузке файла, он закачивает его и сохраняет локально в кеш. В деструкторе локальная копия убивается. А где его убивать сейчас?

System.GC.Collect(0) должен помочь

Здравствуйте Аноним, Вы писали:

АШ>> ...они убрали деструкторы. Предлагаемая взамен комбинация Finalize/Dispose не гарантирует того, что гарантировал автоматический деструктор C++. Все хорошо, если освобождаемые ресурсы в памяти, то есть подвласны сборщику мусора. Но бывают ситуации когда это не так:

А>>>А почему бы не сделать метод close() и вызывать его вместо деструктора ? :)

АШ>>Это решение "в лоб". (Кстати вышеупомятутый Dispose так и предлагают использовать). Кто гарантирует что я смогу вызвать этот Close? :???: В случае исключительных ситуаций выполнение кода может быть не совсем детерминировано. Это ж что ж возвращаемся в прошлый век?
АШ>>"Контролируй друже то шо пышеш, бо реализовать аналог smart pointer-а теперь низя"

АШ>>Андрей

А>Андрей, я в .Net не силен, но раз уж микрософт столько содрала с Java, то наверняка есть и аналог try{}finally{}

Конечно такие вещи есть, но ими можно обложить конкретный блок кода, а деструктор гарантирует "целостность данных", если можно так выразится, глобально. Неважно закончилось выполнение успешно или по исключению, обрабатывал я иск. ситуации или нет, деструктор вызывается ВСЕГДА И АВТОМАТИЧЕСКИ. Именно этим и был всегда силен С++.

Андрей.

Здравствуйте IT, Вы писали:

IT>Здравствуйте Андрей Швыдкый, Вы писали:

АШ>>Есть класс, представляющий из себя нечто вроде моникера для файлов лежащих далеко в "медленной" сети. При первой загрузке файла, он закачивает его и сохраняет локально в кеш. В деструкторе локальная копия убивается. А где его убивать сейчас?

IT>System.GC.Collect(0) должен помочь :)

В чем? Он сможет только сам "моникер" убить, а удалить файл из файловой системы он не сможет :)

Андрей

А>>Андрей, я в .Net не силен, но раз уж микрософт столько содрала с Java, то наверняка есть и аналог try{}finally{}

А>Конечно такие вещи есть, но ими можно обложить конкретный блок кода, а деструктор гарантирует "целостность данных", если можно так выразится, глобально. Неважно закончилось выполнение успешно или по исключению, обрабатывал я иск. ситуации или нет, деструктор вызывается ВСЕГДА И АВТОМАТИЧЕСКИ. Именно этим и был всегда силен С++.

А>Андрей.



Интересный момент, все вышесказанное написал я, а на сайте пишет что Аноним :))
Где тут товарищи отвечающие за движок сайта?

Андрей

Здравствуйте Андрей Швыдкый, Вы писали:

IT>>System.GC.Collect(0) должен помочь

АШ>В чем? Он сможет только сам "моникер" убить, а удалить файл из файловой системы он не сможет

А кто сможет? Деструктор? Так он будет вызван автоматически перед освобождением памяти, занимаемой объектом.

Здравствуйте IT, Вы писали:

IT>Здравствуйте Андрей Швыдкый, Вы писали:
А хрен значет как.

Деструктор то будет вызван этот, точно. В бетах да бало не так вы не гарантировали
что он будет вызван, поэтому у GC был какйтотам метод (вроде RegisterForFinalizeOnShutdown)
В релизе поведение же изменилось, и деструктор (то есть метод Finalize) будет вызван для
вашего объекта всегда. Только вот файл в метленно сети вам может и не получиться удалить,
поскольку любой деструктор не имее права выполняться более 7 секунд. Поэтому предлагаю создать
из вашего деструктора второй поток который и очистит нужные вам ресурсы.

Здравствуйте MrOrbit, Вы писали:

А я согласен с Андреем. Копировать с Явы глупость было не зачем. Как минимум для структур можно было дать возможность создавать деструкторы. Тогда их можно было использовать как затравку для смартпоинтеров.

Да и шаблоны не ввели зря. Одна радость MC++. Верно IT?

Здравствуйте VladD2:

VD>А я согласен с Андреем. Копировать с Явы глупость было не зачем.

Как проведший год под J2SE/EE свидетельствую — ужасно раздражающее отсутствие настоящих деструкторов в джаве продолжается и под НЕТом. Честно говоря мне вообще кажется что за 5 лет могли сделать в джаве и перегрузку операторов (кстати судя по тому во что она превратилась в C# с индексерами может без нее и правда лучше? ) и шаблоны — одна надежда что конкуренция с НЕТ подстегнет Sun и наоборот, а то кажется мне что и шарп это не плюсы, а очередной басик.

А вообще то (ИМХО) не скоро родится второй Страуструп (((

Здравствуйте MrOrbit, Вы писали:

MO>Здравствуйте IT, Вы писали:

MO>Деструктор то будет вызван этот, точно. В бетах да бало не так вы не гарантировали
MO>что он будет вызван, поэтому у GC был какйтотам метод (вроде RegisterForFinalizeOnShutdown)
MO>В релизе поведение же изменилось, и деструктор (то есть метод Finalize) будет вызван для
MO>вашего объекта всегда. Только вот файл в метленно сети вам может и не получиться удалить,
MO>поскольку любой деструктор не имее права выполняться более 7 секунд. Поэтому предлагаю создать
MO>из вашего деструктора второй поток который и очистит нужные вам ресурсы.

7 секунд? Дурацкое ограничение... А если у меня там диалог вылазиет? Откуда эта информация? Где можно почитать?

Андрей.

Здравствуйте Аноним, Вы писали:

А>Здравствуйте Аноним, Вы писали:

АШ>>> ...они убрали деструкторы. Предлагаемая взамен комбинация Finalize/Dispose не гарантирует того, что гарантировал автоматический деструктор C++. Все хорошо, если освобождаемые ресурсы в памяти, то есть подвласны сборщику мусора. Но бывают ситуации когда это не так:

А>>>>А почему бы не сделать метод close() и вызывать его вместо деструктора ? :)

АШ>>>Это решение "в лоб". (Кстати вышеупомятутый Dispose так и предлагают использовать). Кто гарантирует что я смогу вызвать этот Close? :???: В случае исключительных ситуаций выполнение кода может быть не совсем детерминировано. Это ж что ж возвращаемся в прошлый век?
АШ>>>"Контролируй друже то шо пышеш, бо реализовать аналог smart pointer-а теперь низя"

АШ>>>Андрей

А>>Андрей, я в .Net не силен, но раз уж микрософт столько содрала с Java, то наверняка есть и аналог try{}finally{}

А>Конечно такие вещи есть, но ими можно обложить конкретный блок кода, а деструктор гарантирует "целостность данных", если можно так выразится, глобально. Неважно закончилось выполнение успешно или по исключению, обрабатывал я иск. ситуации или нет, деструктор вызывается ВСЕГДА И АВТОМАТИЧЕСКИ. Именно этим и был всегда силен С++.

А>Андрей.

Так ведь блок finally выполняется ВСЕГДА И АВТОМАТИЧЕСКИ
(и когда был exception и когда не было exception'а тоже !).
Это и выручает.

Здравствуйте Nikita Dolgov, Вы писали:

ND>...кстати судя по тому во что она превратилась в C# с индексерами может без нее и правда лучше?

Не... это ты зря. Индексаторы это правильно утянутая идея из Дельфи дает большУю гибкость по сравнению с перегрузкой оператора [] в С++.

ND>...и шаблоны — одна надежда что конкуренция с НЕТ подстегнет Sun и наоборот

Это точьно! Вот только слабо. Я бы на месте MS добавил бы в Шарп шаблоны и деструкторы (в том числе и для структур).

Остальное меня и так устраиваю.

ND>... а то кажется мне что и шарп это не плюсы, а очередной басик.

А мне и нужне бейсик, но с возможностями С, а не ограничениями и тормозами как у VB6. Если тебе нужен монстр, то чем тебя не устраивает MC++? Там есть все. И он генерирует переносимый MSIL (ассемблер от MS).

ND>А вообще то (ИМХО) не скоро родится второй Страуструп (((

Ну, Страусу тоже за многие глупости нужно перья по выщипывать. Иначе бы никто про новые языки и думать не стал бы.

Здравствуйте Рек, Вы писали:

Рек>Так ведь блок finally выполняется ВСЕГДА И АВТОМАТИЧЕСКИ
Рек>(и когда был exception и когда не было exception'а тоже !).
Рек>Это и выручает.

А-га. Только я раньше (в сложном и дремучем С++) просто один раз писал хелпер-класс который автоматически освобождал ресурсы, а потом всю жизнь жил спокойно. А теперь нужно писать гору кода. Причем все усложняется если переменная ссылающаяся на ресурс объявлена как член класса или структуры.

АШ>7 секунд? Дурацкое ограничение... А если у меня там диалог вылазиет? Откуда эта информация? Где можно почитать?

Диалог в деструкторе? И что будем спрашивать "Объект уничтожается, продожить?".
На сколько я знаю, Finalize вызываются в отдельном потоке, возможно это ограничение необходимо
для предотварщения зависания этого потока и вместе с ним и самого мусорщика.

Отсутствие нормальных деструкторов — это плата за эффективность работы мусорщика.

Здравствуйте al, Вы писали:

АШ>>7 секунд? Дурацкое ограничение...
>А если у меня там диалог вылазиет?

Придётся зодтать второй поток.

>Откуда эта информация?
Из .NET.
>Где можно почитать?
Нигде.

al>Диалог в деструкторе? И что будем спрашивать "Объект уничтожается, продожить?".


al>На сколько я знаю, Finalize вызываются в отдельном потоке,
Правильно ты знаешь.

al>возможно это ограничение необходимо
al>для предотварщения зависания этого потока и вместе с ним и самого мусорщика.
Не возможноо а так оно и есть

al>Отсутствие нормальных деструкторов — это плата за эффективность работы мусорщика.

Я вот тут никак не просеку ЧЕМ ВАС ВСЕХ МЕТОД Finalize НЕ УСТРАИВАЕТ
Объяснити ка мне.

Здравствуйте MrOrbit, Вы писали:

MO>Я вот тут никак не просеку ЧЕМ ВАС ВСЕХ МЕТОД Finalize НЕ УСТРАИВАЕТ
MO>Объяснити ка мне. :???:

Finalize устраивает не всех и не вегда, т.к. во первых он вызывается в отдельном
потоке, поэтому могут иметь место проблемы с синхронизацией. Во вторых он вызывается
не сразу после освобождения всех ссылок на объект, и, на сколько я знаю, может вообще не
вызываться, например, при завершении работы приложения. Об этом писал Dr.GUI — из его
статьи я понял, что использовать Finalize — последнее дело. На мой взгляд использовать Fianlize
можно только в отладочных целях — проверить в нем, был ли обект правильно деинициализировн
перед освобождением последней ссылки и т.п.

Здравствуйте Аноним,

А>использовать Finalize — последнее дело.

Это просто джава номер 2 => finalize практически бесполезен, все ресурсы типа файлов/сокетов в нем в принципе не должны закрываться т.е. безальтернативно надо делать ручной cleanUp() (в НЕТ кажется даже стандартный интерфейс ввели для этого).