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

К>- если человек когда-то писал на C++, но не делает это сейчас
К>- если человек пишет на C++, но не интересуется, не изучал С++11
К>то он не знает современный C++

на днях в стандарт приняли filesystem ts, так что человек незнакомый с ним — теперь тоже не знает C++

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

VD>Память просто никто не выгружает. Сменил указатель на новое значение и все. Забыл про то что там было старое. Все выгружается автоматом. Нет ссылок, нет объекта.

Извините, что влезаю (я вообще на Дельфи пишу).

А что будет, если объект держит хэндл на файл с монопольным доступом? И пока не освободится, файл не отпустит. Как решить эту проблему?

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

F>А что будет, если объект держит хэндл на файл с монопольным доступом? И пока не освободится, файл не отпустит. Как решить эту проблему?

Если этот объект имеет "финализатор" (специальный метод, похожий на деструктор), и в этом финализаторе корректно освобождает "хэндл на файл с монопольным доступом", то через некоторое время — когда мусорщик решит прибраться — при убийстве объекта файл будет освобожден. Если хэндл в финализаторе не освобождается, то файл будет залочен, пока программа работает.

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

F>Извините, что влезаю (я вообще на Дельфи пишу).
F>А что будет, если объект держит хэндл на файл с монопольным доступом? И пока не освободится, файл не отпустит. Как решить эту проблему?
Через применение IDisposable.

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

ARK>Если этот объект имеет "финализатор" (специальный метод, похожий на деструктор), и в этом финализаторе корректно освобождает "хэндл на файл с монопольным доступом", то через некоторое время — когда мусорщик решит прибраться — при убийстве объекта файл будет освобожден. Если хэндл в финализаторе не освобождается, то файл будет залочен, пока программа работает.

Ну то есть, пока GC не приберётся, другой объект не сможет получить доступ к файлу?

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

ARK>>Если этот объект имеет "финализатор" (специальный метод, похожий на деструктор), и в этом финализаторе корректно освобождает "хэндл на файл с монопольным доступом", то через некоторое время — когда мусорщик решит прибраться — при убийстве объекта файл будет освобожден. Если хэндл в финализаторе не освобождается, то файл будет залочен, пока программа работает.

F>Ну то есть, пока GC не приберётся, другой объект не сможет получить доступ к файлу?

Ну, как правильно выше заметили, по-хорошему неуправляемые ресурсы надо освобождать вручную с помощью IDisposable и using.
Я свой пост написал в предположении "как быть, если ручного освобождения нет". В таком случае да, придется ждать мусорщика (и, кстати, нет гарантии, что объект с хэндлом вообще будет удален).

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

К>>то он не знает современный C++
BZ>на днях в стандарт приняли filesystem ts, так что человек незнакомый с ним — теперь тоже не знает C++

Век живи, век учись

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

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

J>В описанной ситуации в плюсах мы получим битый указатель, а шарпе мемлик, это понятно.
J>Меня вот какой вопрос больше интересует. В плюсах при использовании какого нить отладочного манагера памяти при нажатии на кнопку, ссылающуюся на убитый менеджер звуков, мы практически гарантированно AV получим и начнем править багу. А вот в .NET обработчик нормально отработает, ошибка будет логическая и возможно плохо заметная. Как с этим бороться ?

В приведенном примере, по идее должны быть явно освобождены ресурсы и менеджер звука будет падать при обращении к драйверу.

А по сути проблема в кривой дизайне.