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

S>Я привел конкретный пример на конкретный вопрос. В ответ, как обычно, получаю абстрактные рассуждения.
S>Вот у меня в системе сейчас текут GDI объекты. И вовсе не из-за управляемого софта, а из-за 100% написанных на мегапродвинутых языках типа С++ IE7.0 и Outlook2007.
S>Может, все-таки хватит фигней страдать?

Угу а у меня rss читалка написаная на NET летом подвешивала систему так что ее не хватало ресурсов, будем и дальше такой же ерундой заниматся?

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


R>Вопрос не в том, почему я не могу создать.
R>Воспрос в следующем. Берём как данность, что есть некая операция типа "отмены" (pop, rollback, что угодно), которая может завершаться неуспешно. И в таком контексте задаёмся следующем вопросом. Если механизм языка (раскрутка стека и деструкторы) при возникновении исключения в деструкторе молча завершает программу, является ли это плохим/неправильным поведением. И если бы язык себя так не вёл, а вёл бы как-то по-другому, то могли бы мы добиться какого хорошего поведения в таком ситуации (когда операция типа "отмены" может проваливаться, повторюсь — это берём как данность).
R>Несколько постов выше с сказал, что язык винить в такой ситуации нет смысла, т.к. если бы он вёл себя как-то по-другому, то мы всё равно бы ничего хорошего не получили. Т.к. в ситуации, когда операция типа "отмены" может проваливаться, получить ничего хорошего нельзя в принципе.

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

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

S>Совершенно верно. Тогда память рискует кончиться сразу при старте приложения, а не через полчаса использования. Радикальное решение вопроса, спасибо

Я скорее имел в виду дырявую реализацию кэширования.

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

S>>Да ну? Сборщик мусора банально соберет ненужную картинку сразу, как только на нее исчезнет ссылка.

FR>Файл не закроет, спроецированный файл не уберет, DX поверхность не освободит, только память почистит, и то не известно когда.

Во-первых, никто не отменял финализаторы. Во-вторых, непонятно, зачем оставлять файл открытым тогда, когда картинка открыта. В-третьих, управление файлами — это из другой оперы, они принципиально принадлежат к классу управляемых ресурсов; для этого в управляемых средах предусмотрены close, Dispose, using и т.д.

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

FR>Угу а у меня rss читалка написаная на NET летом подвешивала систему так что ее не хватало ресурсов, будем и дальше такой же ерундой заниматся?

Как захотите. Вот я лично вижу два мегапроекта, написанных мегакрутыми парнями, причем у одного версия 7.0, а у другого — ажно 12.0. То есть затраты на QA в них обоих превышают суммарные затраты на все проекты, в которых я за свою жизнь поучаствовал, в несколько раз. И, естественно, в них применяются самые распродвинутые фреймворки на C++, которые вот здесь

Автор: FR
Дата: 24.12.07

рекламируются как легко справляющиеся с утечками. Однако ж вот дела, текут они хуже, чем Janus, написанный в свободное от отдыха время крохотной кучкой энтузиастов.
Смею полагать, что янус на плюсах, буде таковой вообще написан, тек бы как дуршлаг.

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

C>>Если картинки — это не просто объекты в памяти, а ссылки на системный или внешний объект, то именно "когда-нибудь в будушем".
S>Я привел конкретный пример на конкретный вопрос. В ответ, как обычно, получаю абстрактные рассуждения.
Кстати, могу еще один интересный пример привести — на SWT в Java точно так же нужно делать dispose() для графических объектов, чтобы их освободить. Однако, это делать можно только вручную (или неявно с помощью иерархии владения) — финализаторы для этого не используются. Как результат — более надежные приложения, так как разработчики вынуждены исправлять утечки.

S>Вот у меня в системе сейчас текут GDI объекты. И вовсе не из-за управляемого софта, а из-за 100% написанных на мегапродвинутых языках типа С++ IE7.0 и Outlook2007.
А в других браузерах и почтовых клиентах — не текут

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

K>Во-первых, никто не отменял финализаторы. Во-вторых, непонятно, зачем оставлять файл открытым тогда, когда картинка открыта. В-третьих, управление файлами — это из другой оперы, они принципиально принадлежат к классу управляемых ресурсов; для этого в управляемых средах предусмотрены close, Dispose, using и т.д.

Конечно не нужно оставлять файл открытым, и поэтому если инструмент не предоставляет средств автоматизировать такие вещи то и приходится это делать по старинке ручками через close и т. п., и управляемые инстументы в таком контексте ничем не лучше неуправляемых (delphi) и хуже чем C++.

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

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

FR>>Угу а у меня rss читалка написаная на NET летом подвешивала систему так что ее не хватало ресурсов, будем и дальше такой же ерундой заниматся?

S>Как захотите. Вот я лично вижу два мегапроекта, написанных мегакрутыми парнями, причем у одного версия 7.0, а у другого — ажно 12.0. То есть затраты на QA в них обоих превышают суммарные затраты на все проекты, в которых я за свою жизнь поучаствовал, в несколько раз. И, естественно, в них применяются самые распродвинутые фреймворки на C++, которые вот здесь

Автор: FR
Дата: 24.12.07

рекламируются как легко справляющиеся с утечками. Однако ж вот дела, текут они хуже, чем Janus, написанный в свободное от отдыха время крохотной кучкой энтузиастов.

Не надо передергивать, может еще сравним за одно и объем кода и функциональность этих приложений?
Или может сравним с той же оперой тоже написоной на C++ и не большой как раз фирмой и гораздо более устойчивой чем IE?

S>Смею полагать, что янус на плюсах, буде таковой вообще написан, тек бы как дуршлаг.

Есть куча стабильных приложений сопоставимых по функциональности и объему с янусом написанных на C++ или том же delphi наверно их авторы забыли сказать что написать такое просто невозможно.

Я думаю будь янус на плюсах по качеству он был бы примерно таким же какой и сейчас.

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

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

FR>>Угу а у меня rss читалка написаная на NET летом подвешивала систему так что ее не хватало ресурсов, будем и дальше такой же ерундой заниматся?

S>Как захотите. Вот я лично вижу два мегапроекта, написанных мегакрутыми парнями, причем у одного версия 7.0, а у другого — ажно 12.0. То есть затраты на QA в них обоих превышают суммарные затраты на все проекты, в которых я за свою жизнь поучаствовал, в несколько раз. И, естественно, в них применяются самые распродвинутые фреймворки на C++, которые вот здесь

Автор: FR
Дата: 24.12.07

рекламируются как легко справляющиеся с утечками. Однако ж вот дела, текут они хуже, чем Janus, написанный в свободное от отдыха время крохотной кучкой энтузиастов.

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

S>Смею полагать, что янус на плюсах, буде таковой вообще написан, тек бы как дуршлаг.

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

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


R>>Вопрос не в том, почему я не могу создать.
R>>Воспрос в следующем. Берём как данность, что есть некая операция типа "отмены" (pop, rollback, что угодно), которая может завершаться неуспешно. И в таком контексте задаёмся следующем вопросом. Если механизм языка (раскрутка стека и деструкторы) при возникновении исключения в деструкторе молча завершает программу, является ли это плохим/неправильным поведением. И если бы язык себя так не вёл, а вёл бы как-то по-другому, то могли бы мы добиться какого хорошего поведения в таком ситуации (когда операция типа "отмены" может проваливаться, повторюсь — это берём как данность).
R>>Несколько постов выше с сказал, что язык винить в такой ситуации нет смысла, т.к. если бы он вёл себя как-то по-другому, то мы всё равно бы ничего хорошего не получили. Т.к. в ситуации, когда операция типа "отмены" может проваливаться, получить ничего хорошего нельзя в принципе.

D>С этим я совершенно согласен. Если в языке есть детерминированные деструкторы, стековые объекты и модель исполнения диктует механизм исключений, жестко базирующийся на раскрутке стека, то такое поведение скорее всего оптимальное.


Я бы даже сказал, что фактически какое именно поведение не важно. Т.к. если операция типа "отмены" может провалиться, то программе уже не поможет никакое конкретное поведение. Можно было бы вместо вызова std::terminate(), назвать поведение undefined behavior, и отдать это на откуп реализации. Скорее всего возможность возникновения такой ситуации просто свидетельствует либо об ошибке дизайна, либо о банальной ошибке в программе.

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

D>>Их можно в глобальную коллекцию загружать и брать оттуда, не удаляя.
S>Совершенно верно. Тогда память рискует кончиться сразу при старте приложения, а не через полчаса использования. Радикальное решение вопроса, спасибо

Кстати вполне распрастраненный паттерн в игрострое, вся память и остальные ресурсы на уровень игры выделяются и освобождаются скопом — http://www.dtf.ru/articles/print.php?id=4071

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

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

S>>>Да ну? Сборщик мусора банально соберет ненужную картинку сразу, как только на нее исчезнет ссылка.

FR>>Файл не закроет, спроецированный файл не уберет, DX поверхность не освободит, только память почистит, и то не известно когда.

K>Во-первых, никто не отменял финализаторы. Во-вторых, непонятно, зачем оставлять файл открытым тогда, когда картинка открыта. В-третьих, управление файлами — это из другой оперы, они принципиально принадлежат к классу управляемых ресурсов; для этого в управляемых средах предусмотрены close, Dispose, using и т.д.


Что и требовалось доказать. От malloc/free никуда не ушли. Соотв. и надёжность/утечки равны таковым при использовании malloc/free. Какие основания ожидать иного?
Далее самое интересное — если мы в управляемой среде можем реализовать надёжное управление некоторыми ресурсами с помощью close/Dispose/using (можем же, правильно?), то в чём проблема при использовании тех же средств, но в других языках и для других ресурсов?

Здравствуйте, Константин Л., Вы писали:
КЛ>1. Как написан Janus не имеет какого-либо значения. Или ты намекаешь что при его написании нах уважаемый топ100 откровенно халтурил? Сомневаюсь.
КЛ>2. Как вы вообще определяете, что они текут? При наличии исходников это бывает сделать очень сложно, а без них и подавно.
Гыгы. Определить это очень легко — достаточно запустить Task Manager. И когда он показывает 5000 GDI хэндлов, выданных одному приложению, и 3000 — другому, то ежу понятно, что дело не в огромном количестве тегов select. А утечка приводит к большому количеству разнообразных спецэффектов: от исчезновения smart tags в офисе и контекстных меню вообще везде, до неработоспособности встроенного поиска в аутлуке.

Здравствуйте, remark, Вы писали:
R>Что и требовалось доказать. От malloc/free никуда не ушли. Соотв. и надёжность/утечки равны таковым при использовании malloc/free. Какие основания ожидать иного?
R>Далее самое интересное — если мы в управляемой среде можем реализовать надёжное управление некоторыми ресурсами с помощью close/Dispose/using (можем же, правильно?), то в чём проблема при использовании тех же средств, но в других языках и для других ресурсов?
Непонятно, как вы собираетесь реализовывать using в "других языках"? Ну, если не рассматривать Nemerle? Понятно, что сам по себе using никак не требует управляемости среды, т.к. разворачивается в совершенно стандартный код, приемлемый в практически любом интересном ЯВУ девяностых годов. По крайней мере, плюсы, дельфи и жава сделали бы это без проблем.

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

S>Здравствуйте, remark, Вы писали:
R>>Что и требовалось доказать. От malloc/free никуда не ушли. Соотв. и надёжность/утечки равны таковым при использовании malloc/free. Какие основания ожидать иного?
R>>Далее самое интересное — если мы в управляемой среде можем реализовать надёжное управление некоторыми ресурсами с помощью close/Dispose/using (можем же, правильно?), то в чём проблема при использовании тех же средств, но в других языках и для других ресурсов?
S>Непонятно, как вы собираетесь реализовывать using в "других языках"? Ну, если не рассматривать Nemerle? Понятно, что сам по себе using никак не требует управляемости среды, т.к. разворачивается в совершенно стандартный код, приемлемый в практически любом интересном ЯВУ девяностых годов. По крайней мере, плюсы, дельфи и жава сделали бы это без проблем.


Во-первых, это совершенно не важно. using — лишь одно средство из.
Во-вторых:

C#:

using (db_conn conn = new db_conn(pool))
{
  //...
}

------------------------->>> C++:

db_conn conn (pool);
//...

Здравствуйте, remark, Вы писали:
R>------------------------->>> C++:

R>

R>db_conn conn (pool);
R>//...
R>

Ну да, то же самое, только наоборот. У юзинга скоуп определен следующей за ним парой скобок, у conn — объемлющей.

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

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


R>Я бы даже сказал, что фактически какое именно поведение не важно. Т.к. если операция типа "отмены" может провалиться, то программе уже не поможет никакое конкретное поведение. Можно было бы вместо вызова std::terminate(), назвать поведение undefined behavior, и отдать это на откуп реализации. Скорее всего возможность возникновения такой ситуации просто свидетельствует либо об ошибке дизайна, либо о банальной ошибке в программе.

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

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

S>Здравствуйте, Константин Л., Вы писали:
КЛ>>1. Как написан Janus не имеет какого-либо значения. Или ты намекаешь что при его написании нах уважаемый топ100 откровенно халтурил? Сомневаюсь.
КЛ>>2. Как вы вообще определяете, что они текут? При наличии исходников это бывает сделать очень сложно, а без них и подавно.
S>Гыгы. Определить это очень легко — достаточно запустить Task Manager. И когда он показывает 5000 GDI хэндлов, выданных одному приложению, и 3000 — другому, то ежу понятно, что дело не в огромном количестве тегов select. А утечка приводит к большому количеству разнообразных спецэффектов: от исчезновения smart tags в офисе и контекстных меню вообще везде, до неработоспособности встроенного поиска в аутлуке.

Прошу прощения, я имел ввиду память. Тем более что "течет" понятие субъективное.

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

[]

S>Ну да, то же самое, только наоборот. У юзинга скоуп определен следующей за ним парой скобок, у conn — объемлющей.

и?

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

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

КЛ>[]

S>>Ну да, то же самое, только наоборот. У юзинга скоуп определен следующей за ним парой скобок, у conn — объемлющей.

КЛ>и?

действительно — и?