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

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

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

Привет всем.

С удивлением обнаружил, что хоть 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'а тоже !).
Рек>Это и выручает.

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

> Предлагаемая взамен комбинация Finalize/Dispose не гарантирует того, что гарантировал автоматический деструктор C++.

Я тут вот что подумал — в С++ деструкторы были атоматическими только для автоматических объектов, т.е. созданых
на стеке. Для обектов, созданных при помощи new всегда птиходится ЯВНО вызывать дестуктор при помощи оператора delete.
В принципе нет никакой разницы, вызывать delete MyObject; или MyObject.CleanUp(); — это просто дело привычки.
Тут сожалели по поводу отсутсвия деструкторов для структурных типов. А что будет, если структурный тип будет "упакован" и превращен
в ссылку на object и сохранен после выхода из области видимости? Ведь в этом случае вызывать деструктор уже нельзя. А когда его вызывать?
Возможно, что и никогда! В итоге получаем что в некоторых случаях деструктор вызывается, а в некоторых нет + система должна думать о том,
был ли упакован каждый структурный тип + программист тоже должен об жтом думать. Уф!

Возможно в некоторых случаях можно решить проблему введя интерфейс типа IUnknown из COM с аналогами методов AddRef / Release. Правда вызывать эти методы придется в ручную, за то при обнулении количества ссылок в Release можно автоматически вызвать метод, заменяющий деструктор. В свое программе
на C++ я делал именно так для некоторых классов, т.к. было совершенно непонятно, в каком месте их следлвало удалять.

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

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

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

Но а каким же образом тогда освобождать ресурсы которые в С++ классически освобождались в деструкторе? (даже в случае возникновения исключительной ситуации)
Взять к примеру файлы отрытые объектом ....

al>Возможно в некоторых случаях можно решить проблему введя интерфейс типа IUnknown из COM с аналогами методов AddRef / Release. Правда вызывать эти методы придется в ручную, за то при обнулении количества ссылок в Release можно автоматически вызвать метод, заменяющий деструктор.

При этом мы поимеем замечательную фичу — если образуются кольцевые ссылки, а затем мы теряем указатель на кольцо — кольцо так и останется в памяти и никогда не прибьется. Особенно страшно это в com в случает separated process сервера. Дерьмо не прибьется даже если процесс завершится. Для серверных приложений это просто катастрофа. Дельфа сроду никогда автоматом объекты не прибивала, однако ж для com подобную фичу сделали, прям как в с++. Как ты думаешь почему?

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

If you do handle precious unmanaged resources (such as file handles) that you want to
close and dispose of as quickly as possible, you ought to implement the IDisposable interface.

The IDisposable interface requires its implementers to define one method, named Dispose( ), to perform whatever cleanup you consider to be crucial. The availability of Dispose( ) is a way for your clients to say "don't wait for Finalize( ) to be called, do it right now."

If you provide a Dispose( ) method, you should stop the garbage collector from calling
Finalize( ) on your object. To stop the garbage collector, you call the static method
GC.SuppressFinalize(), passing in the this pointer for your object. Your Finalize( ) method
can then call your Dispose( ) method. Thus, you might write:

public void Dispose( )
{
// perform clean up
// tell the GC not to finailze
GC.SuppressFinalize(this);
}
public override void Finalize( )
{
Dispose( );
base.Finalize( );
}

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

AVK>При этом мы поимеем замечательную фичу — если образуются кольцевые ссылки, а затем мы теряем указатель на кольцо — кольцо так и останется в памяти и никогда не прибьется. Особенно страшно это в com в случает separated process сервера. Дерьмо не прибьется даже если процесс завершится. Для серверных приложений это просто катастрофа. Дельфа сроду никогда автоматом объекты не прибивала, однако ж для com подобную фичу сделали, прям как в с++. Как ты думаешь почему?

А не надо терять указатели на обекты! Кроме того в моем предложении AddRef / Release не освобождают объекты (как в COM), а только вызывают "деструктор".
Очиской памяти по прежнему занимается мусорщик, при чем в Finalize можно проверить чему равен счетчик ссылок, и если он не нулевой, то значит где-то не была освобождена ссылка — ищите ошибку!

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

al>А не надо терять указатели на обекты! Кроме того в моем предложении AddRef / Release не освобождают объекты (как в COM), а только вызывают "деструктор".
И все же — как поступать в случае кольцевых ссылок?

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

AVK>И все же — как поступать в случае кольцевых ссылок?

А надо просто думать о них. Например если A ссылается B, а B ссылается на A, то или A или B не должны вызывать
AddRef для B или A соответсвенно. Интересно, а чем в этой ситуации помогали деструкторы C++? Та же ситуация:
в дестукторе A вызывается деструктор B в котором уже не должен вызываться деструктор A (или наоборот). Просто сама
ситуация рекурсивных ссылок является нетривиальной и ничего кроме собственной головы (даже смартпойнтеры) не поможет!

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

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

AVK>>И все же — как поступать в случае кольцевых ссылок?

al>А надо просто думать о них. Например если A ссылается B, а B ссылается на A, то или A или B не должны вызывать
al>AddRef для B или A соответсвенно.
Да уж, то что ты предлагаешь здорово упростит жизнь.

al> Интересно, а чем в этой ситуации помогали деструкторы C++? Та же ситуация:
al>в дестукторе A вызывается деструктор B в котором уже не должен вызываться деструктор A (или наоборот).
Нет, этот случай как раз обычно не встречается или по крайней мере виден сразу. Проблема возникает когда А ссылается на В, В на С а С на А. Из корня при этом есть ссылка только скажем на А.

al> Просто сама
al>ситуация рекурсивных ссылок является нетривиальной и ничего кроме собственной головы (даже смартпойнтеры) не поможет!
GC однако помогает. Идеология managed языков такова что память не может быть потеряна ни при каких условиях. Так что твои предложения не прокатывают.

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

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

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

AVK>>>И все же — как поступать в случае кольцевых ссылок?

al>>А надо просто думать о них. Например если A ссылается B, а B ссылается на A, то или A или B не должны вызывать
al>>AddRef для B или A соответсвенно.
AVK>Да уж, то что ты предлагаешь здорово упростит жизнь.

А ни кто и не обещает простой жизни — сложная программа это всегда сложная прогамма.

al>> Просто сама
al>>ситуация рекурсивных ссылок является нетривиальной и ничего кроме собственной головы (даже смартпойнтеры) не поможет!
AVK>GC однако помогает. Идеология managed языков такова что память не может быть потеряна ни при каких условиях. Так что твои предложения не прокатывают.

Реч идет не о памяти, а об освобождении в деструкторе других ресурсов ОС — файлов, потоков и т.п. Проблема в том, что архетектура GC не допускает существования деструкторв (вернее допускает, но это очень не эффективное решение — запускать сборку мусора после освобождения любой ссылки). В .Net
освобождение обектов происходит по мере необходимости — нужна память — запускается GC — память еще есть — GC отдыхает. С точки хрения скорости работы это очень эффективно. Так что GC однако не помогает (почитай внимательно корневой вопрос).

Теперь ответь на вопрос: Как деструктор C++ помогает боротся с кольцевыми ссылками? О что, такой умный? Кто ему расскажет про то, что ссылка кольцевая?

PS: Афоризм: В .Net деструкторов Net

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

al>Реч идет не о памяти, а об освобождении в деструкторе других ресурсов ОС — файлов, потоков и т.п. Проблема в том, что архетектура GC не допускает существования деструкторв (вернее допускает, но это очень не эффективное решение — запускать сборку мусора после освобождения любой ссылки). В .Net
al>освобождение обектов происходит по мере необходимости — нужна память — запускается GC — память еще есть — GC отдыхает. С точки хрения скорости работы это очень эффективно. Так что GC однако не помогает (почитай внимательно корневой вопрос).

al>Теперь ответь на вопрос: Как деструктор C++ помогает боротся с кольцевыми ссылками? О что, такой умный? Кто ему расскажет про то, что ссылка кольцевая?

Казнить нельзя помиловать.

Если сделать кольцо объектов, а потом корневой объект удалить (напр., он лежал на стеке, и мы вышли из контекста), то он за собой снесет всех друзей.

В случае подсчета ссылок — на стеке лежит смарт-поинтер (CComPtr<I...>), который просто забудет этого объекта и все тут.

al>PS: Афоризм: В .Net деструкторов Net

Кстати, если порассуждать о технологиях.

Можно (было бы) назначать объектам свойство "моментального разрушения", т.е. переключатель немедленного/отложенного разрушения по Release()==0.

Поскольку при выходе за контекст теряется последняя ссылка, то объект-хелпер прекрасно сработает.

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

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

al>>Реч идет не о памяти, а об освобождении в деструкторе других ресурсов ОС — файлов, потоков и т.п. Проблема в том, что архетектура GC не допускает существования деструкторв (вернее допускает, но это очень не эффективное решение — запускать сборку мусора после освобождения любой ссылки). В .Net
al>>освобождение обектов происходит по мере необходимости — нужна память — запускается GC — память еще есть — GC отдыхает. С точки хрения скорости работы это очень эффективно. Так что GC однако не помогает (почитай внимательно корневой вопрос).

al>>Теперь ответь на вопрос: Как деструктор C++ помогает боротся с кольцевыми ссылками? О что, такой умный? Кто ему расскажет про то, что ссылка кольцевая?

К>Казнить нельзя помиловать.

К>Если сделать кольцо объектов, а потом корневой объект удалить (напр., он лежал на стеке, и мы вышли из контекста), то он за собой снесет всех друзей.

К>В случае подсчета ссылок — на стеке лежит смарт-поинтер (CComPtr<I...>), который просто забудет этого объекта и все тут.

Что за задача такая, где на стеке будет лежать кольцо объектов? На сколько я понимаю, такие структуры данных в программах живут дольше, чем вызов огного метода. В этом случае все создается в куче, а не на стеке. А с кучей C++ никик не помогал (не вызвал delete/деструктор — потерял память).

al>>PS: Афоризм: В .Net деструкторов Net

К>Кстати, если порассуждать о технологиях.

К>Можно (было бы) назначать объектам свойство "моментального разрушения", т.е. переключатель немедленного/отложенного разрушения по Release()==0.

К>Поскольку при выходе за контекст теряется последняя ссылка, то объект-хелпер прекрасно сработает.

Не обязательно, что при выходе из контекста теряется последняя ссылка. Если структора была упакована в object, то ссылка может и сохраниться в какой-то глобальной переменной. Я об этом уже говорил.

Мне кажется, что отсутсвие деструкторов скорее психологическая, чем технологическая проблема перехода с C++ на .Net. Есть масса языков (например, C) в которых нет деструкторов (да и классов). Однако это не мешает использовать эти языки для написания достаточно сложных программ.

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

al>>>освобождение обектов происходит по мере необходимости — нужна память — запускается GC — память еще есть — GC отдыхает. С точки хрения скорости работы это очень эффективно. Так что GC однако не помогает (почитай внимательно корневой вопрос).

А реалтайм не пропадет?
Если при выделении памяти начнет пыхтеть мусоросборник... по 7 сек. на деструктор...

al>>>Теперь ответь на вопрос: Как деструктор C++ помогает боротся с кольцевыми ссылками? О что, такой умный? Кто ему расскажет про то, что ссылка кольцевая?

К>>Казнить нельзя помиловать.

К>>Если сделать кольцо объектов, а потом корневой объект удалить (напр., он лежал на стеке, и мы вышли из контекста), то он за собой снесет всех друзей.

К>>В случае подсчета ссылок — на стеке лежит смарт-поинтер (CComPtr<I...>), который просто забудет этого объекта и все тут.

al>Что за задача такая, где на стеке будет лежать кольцо объектов? На сколько я понимаю, такие структуры данных в программах живут дольше, чем вызов огного метода. В этом случае все создается в куче, а не на стеке. А с кучей C++ никик не помогал (не вызвал delete/деструктор — потерял память).

Кольцо объектов — ну, например, std::list. И ничего не теряет, потому что умеет.

А чтобы delete вызывать — используются локальные смарт-поинтеры.

К>>Кстати, если порассуждать о технологиях.

К>>Можно (было бы) назначать объектам свойство "моментального разрушения", т.е. переключатель немедленного/отложенного разрушения по Release()==0.

К>>Поскольку при выходе за контекст теряется последняя ссылка, то объект-хелпер прекрасно сработает.

al>Не обязательно, что при выходе из контекста теряется последняя ссылка. Если структора была упакована в object, то ссылка может и сохраниться в какой-то глобальной переменной. Я об этом уже говорил.

Выход есть. Проверять число ссылок в деструкторе смарт-поинтера.
assert(pointee->Release() == 0)

так как сохранение объекта на стороне — это либо запроектированная фича, либо явный баг.

al>Мне кажется, что отсутсвие деструкторов скорее психологическая, чем технологическая проблема перехода с C++ на .Net. Есть масса языков (например, C) в которых нет деструкторов (да и классов). Однако это не мешает использовать эти языки для написания достаточно сложных программ.

Этак можно алгоритм с С++ на Фортран перетащить. (например — компильнуть, а потом дизассемблировать).

Теряется красота языка, вот в чем дело.

Есть например, масса языков, где нет красиво сделанной многозадачности. (контрпримеры — Оккам и Ада). Это же не повод, чтобы и оттуда выкинуть.

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

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

al>>>>освобождение обектов происходит по мере необходимости — нужна память — запускается GC — память еще есть — GC отдыхает. С точки хрения скорости работы это очень эффективно. Так что GC однако не помогает (почитай внимательно корневой вопрос).

К>А реалтайм не пропадет?
К>Если при выделении памяти начнет пыхтеть мусоросборник... по 7 сек. на деструктор...

Пропадет! Читали Лицензию на Java (а в .Net — то же самое)? "ТЕХНОЛОГИЯ "JAVA" НЕ ГАРАНТИРУЕТ БЕЗУПРЕЧНОЙ РАБОТЫ И НЕ РАЗРАБАТЫВАЛАСЬ, НЕ ПРОИЗВОДИЛАСЬ И НЕ ПРЕДНАЗНАЧЕНА ДЛЯ ИСПОЛЬЗОВАНИЯ ИЛИ ПРОДАЖИ С ЦЕЛЬЮ ИСПОЛЬЗОВАНИЯ В РЕЖИМЕ РЕАЛЬНОГО ВРЕМЕНИ ДЛЯ УПРАВЛЕНИЯ ОПАСНЫМ ОБОРУДОВАНИЕМ" — GC — главная причина этого. Да и сама Windows ничего не гарантирует — когда ей придет в голову свой своп "крутить" — никто не знает. Но с GC — не так все плохо — он работает в отдельном потоке, кроме того очищается только столько памяти, cколько нужно.

К>Кольцо объектов — ну, например, std::list. И ничего не теряет, потому что умеет.

И кто там на кого ссылается? Конец на начало?

К>Выход есть. Проверять число ссылок в деструкторе смарт-поинтера.
assert(pointee->>Release() == 0)

В .Net нет ни каких Release, там нет учета колличества ссылок на объект (как в COM), так что проверять нечего.

К>так как сохранение объекта на стороне — это либо запроектированная фича, либо явный баг.

Скорее всего фича (например, структуры добавляются в список, зачем создавать копию структуры, когда можно сохранить на нее ссылку?).

К>Есть например, масса языков, где нет красиво сделанной многозадачности. (контрпримеры — Оккам и Ада). Это же не повод, чтобы и оттуда выкинуть.

А в C++ есть красивая многозадачность?

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

al>>>освобождение обектов происходит по мере необходимости — нужна память — запускается GC — память еще есть — GC отдыхает. С точки хрения скорости работы это очень эффективно. Так что GC однако не помогает (почитай внимательно корневой вопрос).

К>>А реалтайм не пропадет?
К>>Если при выделении памяти начнет пыхтеть мусоросборник... по 7 сек. на деструктор...

al>Пропадет! Читали Лицензию на Java (а в .Net — то же самое)? "ТЕХНОЛОГИЯ "JAVA" НЕ ГАРАНТИРУЕТ БЕЗУПРЕЧНОЙ РАБОТЫ И НЕ РАЗРАБАТЫВАЛАСЬ, НЕ ПРОИЗВОДИЛАСЬ И НЕ ПРЕДНАЗНАЧЕНА ДЛЯ ИСПОЛЬЗОВАНИЯ ИЛИ ПРОДАЖИ С ЦЕЛЬЮ ИСПОЛЬЗОВАНИЯ В РЕЖИМЕ РЕАЛЬНОГО ВРЕМЕНИ ДЛЯ УПРАВЛЕНИЯ ОПАСНЫМ ОБОРУДОВАНИЕМ" — GC — главная причина этого. Да и сама Windows ничего не гарантирует — когда ей придет в голову свой своп "крутить" — никто не знает. Но с GC — не так все плохо — он работает в отдельном потоке, кроме того очищается только столько памяти, cколько нужно.

Windows CE 3.0 (и выше?) была заявлена как реалтайм. Правда, не для ядерных реакторов...

К>>Кольцо объектов — ну, например, std::list. И ничего не теряет, потому что умеет.

al>И кто там на кого ссылается? Конец на начало?

Кольцевая ссылка — это a->...->a.
Двусвязный список ( a <-> b <->... ) — это всегда кольцевые ссылки.

Просто у std::list четко определено, кто в доме хозяин. (list а не его узлы).

К>>Выход есть. Проверять число ссылок в деструкторе смарт-поинтера.
assert(pointee->>>Release() == 0)

al>В .Net нет ни каких Release, там нет учета колличества ссылок на объект (как в COM), так что проверять нечего.

Ну да, поезд уже ушел. Будем ждать технологии .Est (правда, работать она будет еще меэттленнеэ)

К>>так как сохранение объекта на стороне — это либо запроектированная фича, либо явный баг.

al>Скорее всего фича (например, структуры добавляются в список, зачем создавать копию структуры, когда можно сохранить на нее ссылку?).

Но возможность диагностики могли бы и оставить...

К>>Есть например, масса языков, где нет красиво сделанной многозадачности. (контрпримеры — Оккам и Ада). Это же не повод, чтобы и оттуда выкинуть.

al>А в C++ есть красивая многозадачность?
Чую, что Ada.Net ее тоже лишится. К щастью, американская военщина не спешит юзать мелкософт.

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


К>Кольцевая ссылка — это a->...->a.
К>Двусвязный список ( a <-> b <->... ) — это всегда кольцевые ссылки.

К>Просто у std::list четко определено, кто в доме хозяин. (list а не его узлы).

На сколько я знаю в std:list не сами хранимые объекты ссылаются друг на друга, а специальные невидимые элементы (черт знает как они называются).
Они ссылаются друг на друга и на сам хранимый объект. Так что проблема очистки списка решается не механизмом деструкторов C++, а специальным кодом, спрятаным в шаблоне. А отсутсвие в C# шаблонов — это уже другая тема.

al>>В .Net нет ни каких Release, там нет учета колличества ссылок на объект (как в COM), так что проверять нечего.

К>Ну да, поезд уже ушел. Будем ждать технологии .Est (правда, работать она будет еще меэттленнеэ)

Как раз отсутствие механизма AddRef / Release и использование GC позволяют без проблем решить проблему кольцевых ссылок (по крайней мере в области выделения / освобождения памяти). На мой взгляд 90% обектов в программе нуждаются только в очистке памяти, никаких других ресурсов OS они не используют.

К>>>Есть например, масса языков, где нет красиво сделанной многозадачности. (контрпримеры — Оккам и Ада). Это же не повод, чтобы и оттуда выкинуть.

al>>А в C++ есть красивая многозадачность?
К>Чую, что Ada.Net ее тоже лишится. К щастью, американская военщина не спешит юзать мелкософт.

Дак ведь раньше говорилось что в Ada ее и так нет (красивой). Так что MS здесь не причем. На счет военщины я бы не судил столь категорично. Расчет зарплаты у них небось не на Ada сделан (хотя очень может быть, что и на COBOL).

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

al>На сколько я знаю в std:list не сами хранимые объекты ссылаются друг на друга, а специальные невидимые элементы (черт знает как они называются).
al>Они ссылаются друг на друга и на сам хранимый объект. Так что проблема очистки списка решается не механизмом деструкторов C++, а специальным кодом, спрятаным в шаблоне. А отсутсвие в C# шаблонов — это уже другая тема.

Вот эти-то элементы и представляют двусвязный список. А что они на себе несут — не суть.

al>>>В .Net нет ни каких Release, там нет учета колличества ссылок на объект (как в COM), так что проверять нечего.

К>>Ну да, поезд уже ушел. Будем ждать технологии .Est (правда, работать она будет еще меэттленнеэ)

al>Как раз отсутствие механизма AddRef / Release и использование GC позволяют без проблем решить проблему кольцевых ссылок (по крайней мере в области выделения / освобождения памяти). На мой взгляд 90% обектов в программе нуждаются только в очистке памяти, никаких других ресурсов OS они не используют.

К>>>>Есть например, масса языков, где нет красиво сделанной многозадачности. (контрпримеры — Оккам и Ада). Это же не повод, чтобы и оттуда выкинуть.

al>>>А в C++ есть красивая многозадачность?
К>>Чую, что Ada.Net ее тоже лишится. К щастью, американская военщина не спешит юзать мелкософт.

al>Дак ведь раньше говорилось что в Ada ее и так нет (красивой).

Я говорил, что Ада — это контрпример. Как раз там есть конструкции языка для многозадачности.

Кароче. Че нам языком молотить. Платформа .Net уже Est. Во имя того, чье имя — Врата, оттуда выхватили деструкторы.

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

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

al>>На сколько я знаю в std:list не сами хранимые объекты ссылаются друг на друга, а специальные невидимые элементы (черт знает как они называются).
al>>Они ссылаются друг на друга и на сам хранимый объект. Так что проблема очистки списка решается не механизмом деструкторов C++, а специальным кодом, спрятаным в шаблоне. А отсутсвие в C# шаблонов — это уже другая тема.

К>Вот эти-то элементы и представляют двусвязный список. А что они на себе несут — не суть.

А вот этот двусвязный список уже живет не на стеке, а в куче (на стеке сидит тоько его оболчка — list). Ни один его элемент не может быть удален автоматически — для каждого нужно явно вызвать delete, которая уже вызовет деструктор. Об этом я и говорил.

Про Аду извини — я обчитался.

К> Кароче. Че нам языком молотить. Платформа .Net уже Est. Во имя того, чье имя — Врата, оттуда выхватили деструкторы.

К> Кароче. Че нам языком молотить. Платформа .Net уже Est. Во имя того, чье имя — Врата, оттуда выхватили деструкторы.

Деструкторы выхвачены во имя автоматического выделения памяти, упаковки и эффективной работы мосорщика. Это не прихоть Sun или MS. Если кто-нибудь придумает как эффективно совместить GC, boxing и деструкторы, тот будет молодец.

На счет молочения языком (и своим, и MS C#) — то правда уже достаточно.