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

FR>>Если на C++ пишешь использую любой высокоуровневый фреймворк то никаких отличий.

VD>Ну, ну. Вот тут еао197 жаловался как-то на то, что в одном проекте приходится увязвать разные библиотеки которые получаются совместимы как уж с ежом только потому, что там были приняты разные политики управления память.

Про управление памятью говорил, есть такое дело. Хуже всего с этим у GDI библиотек, но там, вероятно, своя специфика.
А вот высокоуровневых С++ библиотек, в которых бы утекали другие ресурсы (GDI хендлы, сокеты, мутексы и пр.) не видел. Хотя приходилось объединять, например, Qt и Crypto++, ACE с Qt, ACE с FOX Toolkit и пр.

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


R>Что и требовалось доказать.

Что требовалось доказать?

R> От malloc/free никуда не ушли.

Ушли. Файлы и память — раные вещи. С файлами работают только части программы, ответственные за ввод/вывод, а с памятью так или иначе работает вся программа.

R>Соотв. и надёжность/утечки равны таковым при использовании malloc/free. Какие основания ожидать иного?

Не равны. Если есть GC, то надёжность сильно возрастает. За счёт того, что в 99% мест, где управление было бы ручным, оно станет автоматическим. А с файлами да, придётся по-преэнемы трахаться. Но это в десятки раз меньше траха, чем с памятью.

R>Далее самое интересное — если мы в управляемой среде можем реализовать надёжное управление некоторыми ресурсами с помощью close/Dispose/using (можем же, правильно?), то в чём проблема при использовании тех же средств, но в других языках и для других ресурсов?

Не можем мы организовать надёжное ручное управление ресурсами! И никто обратного не утверждал. Самое надёжное управление — это автоматическое.

В других языках зато либо вообще отсутсвует возможность автоматического управления ресурсами (C), либо это делается так, что хочется проклинать и язык, и ресурсы (C++). Д а и что тут "другие"? Языков, требующих GC немало, они не ограничиваются Java/C#. Так вот, при этом ручное управление ресурсами одинаково хорошо реализовано и в С, и в C++, и в C#. Значит, у языков с GC есть некоторое преимущество.

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

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

Чем это они хуже?

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

K>Чем это они хуже?

Тем что в них управлять ресурсами чуть сложнее чем в C++.

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

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

R>>Что и требовалось доказать.

K>Что требовалось доказать?

R>> От malloc/free никуда не ушли.

K>Ушли. Файлы и память — раные вещи. С файлами работают только части программы, ответственные за ввод/вывод, а с памятью так или иначе работает вся программа.

R>>Соотв. и надёжность/утечки равны таковым при использовании malloc/free. Какие основания ожидать иного?

K>Не равны. Если есть GC, то надёжность сильно возрастает. За счёт того, что в 99% мест, где управление было бы ручным, оно станет автоматическим. А с файлами да, придётся по-преэнемы трахаться. Но это в десятки раз меньше траха, чем с памятью.

R>>Далее самое интересное — если мы в управляемой среде можем реализовать надёжное управление некоторыми ресурсами с помощью close/Dispose/using (можем же, правильно?), то в чём проблема при использовании тех же средств, но в других языках и для других ресурсов?

K>Не можем мы организовать надёжное ручное управление ресурсами! И никто обратного не утверждал. Самое надёжное управление — это автоматическое.

K>В других языках зато либо вообще отсутсвует возможность автоматического управления ресурсами (C), либо это делается так, что хочется проклинать и язык, и ресурсы (C++). Д а и что тут "другие"? Языков, требующих GC немало, они не ограничиваются Java/C#. Так вот, при этом ручное управление ресурсами одинаково хорошо реализовано и в С, и в C++, и в C#. Значит, у языков с GC есть некоторое преимущество.


Забудем на время про память, и рассмотрим все остальные ресурсы — файла, сокеты, соединения с БД, графические хэндлы и всевозможные хэндлы различных библиотек. Программисты на управляемых языках умеют писать программы безопасные по отношению к этим ресурсам?


з.ы. не знаю как ты пишешь на С++, но я пишу так и ничего не проклинаю:

file f ("data");
//...

Этот фрагмент не менее надёжен, чем аналог на управляемом языке.
з.з.ы. Аналогично работаю с памятью. Это аналогично не менее надёжно. Никаких утечек не помню на протяжении лет...

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

K>>Чем это они хуже?

FR>Тем что в них управлять ресурсами чуть сложнее чем в C++.

В 99% случаев ими вообще не нужно управлять. Зато в этих 99% случаев, когда в C#/Java всё просто и логично, в C++ — кошмар.

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

R>Забудем на время про память, и рассмотрим все остальные ресурсы — файла, сокеты, соединения с БД, графические хэндлы и всевозможные хэндлы различных библиотек.

Я же говорю — с памятью обычно работы гораздо больше. К тому же, с памятью попадаются гораздо более изощрённые ситуации, чем со всем остальным. Хэндлы — это от лукавого, если бы ОС изначально проектировалась в расчёте на managed-среду, то таких проблем не возникало бы в принципе. В соединении с БД аналогично: всякие кэши и прочее мог бы собирать GC, а явно управлять нужно управлять сокетом/файлом/расшаренной памятью. Т.е. вручную есть смысл управлять теми ресурсами, к которым имеет доступ несколько процессов. В данном случае вообще, мы вынуждены управлять не временем жизни, а лишь временем эксклюзивного доступа к ресурсу.

R> Программисты на управляемых языках умеют писать программы безопасные по отношению к этим ресурсам?

Ага. А что им должно мешать?

R>з.ы. не знаю как ты пишешь на С++, но я пишу так и ничего не проклинаю:
R>

R>file f ("data");
R>//...
R>

R>Этот фрагмент не менее надёжен, чем аналог на управляемом языке.
R>з.з.ы. Аналогично работаю с памятью. Это аналогично не менее надёжно. Никаких утечек не помню на протяжении лет...

Это тривиальный случай. Вообще, в случае с файлами как правило не приходится сильно извращаться. С памятью бывает полный ППЦ. Например, те же вещи связанные с генерацией ДКА по регулярному выражению. Или задача на ICFP 2007 (интерпретатор генов), которая _оптимально_ в случае с GC решается легко и естественно, а без GC приходится извращаться. Или та, задача, которую я решаю сейчас — выделение из прайс-листов полезной информации и запихивание её в БД. Вот сижу, смотрю на свой код на C#, и думаю: до чего же надо иметь извращённый мозг, чтобы во всей этой трёхэтажной алгоритмике, вовсю нашпигованной эвристикой, ещё и памятью управлять?

ЗЫ: А что если надо открыть файл, и вернуть кортеж, содержащий в том числе и хэндл, а потом этот кортеж учавтствует в формировании множеств элеметов (которые так же содержат хэндл), которые помещаются в узлы некого дерева, причём эти множества могут дублироваться в разных узлах? А что если потом это дерево несколько раз хитро обходится и на каждом обходе строится некая модификация дерева? И как потом всё это удалить, затрагивая лишь то, на что не осталось ссылок?

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

FR>>Тем что в них управлять ресурсами чуть сложнее чем в C++.

K>В 99% случаев ими вообще не нужно управлять. Зато в этих 99% случаев, когда в C#/Java всё просто и логично, в C++ — кошмар.

Ваши страхи по поводу C++ сильно преувеличены.

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

K>ЗЫ: А что если надо открыть файл, и вернуть кортеж, содержащий в том числе и хэндл, а потом этот кортеж учавтствует в формировании множеств элеметов (которые так же содержат хэндл), которые помещаются в узлы некого дерева, причём эти множества могут дублироваться в разных узлах? А что если потом это дерево несколько раз хитро обходится и на каждом обходе строится некая модификация дерева? И как потом всё это удалить, затрагивая лишь то, на что не осталось ссылок?

А как вы будете все это делать с GC, если все это нужно будет действительно _удалить_, а не оставить в мусоре до следующего прихода GC?

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

K>Это тривиальный случай. Вообще, в случае с файлами как правило не приходится сильно извращаться. С памятью бывает полный ППЦ. Например, те же вещи связанные с генерацией ДКА по регулярному выражению. Или задача на ICFP 2007 (интерпретатор генов), которая _оптимально_ в случае с GC решается легко и естественно, а без GC приходится извращаться. Или та, задача, которую я решаю сейчас — выделение из прайс-листов полезной информации и запихивание её в БД. Вот сижу, смотрю на свой код на C#, и думаю: до чего же надо иметь извращённый мозг, чтобы во всей этой трёхэтажной алгоритмике, вовсю нашпигованной эвристикой, ещё и памятью управлять?

Мне кажется у тебя неверная предросылка, о том что С++ програмист управляет памятью. На самом деле опытный профи совершенно не будет тратить на это время и переложит все управление на обертки.

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

M>Мне кажется у тебя неверная предросылка, о том что С++ програмист управляет памятью. На самом деле опытный профи совершенно не будет тратить на это время и переложит все управление на обертки.

Я знаю про всякие мутации смартпоинтеров и про способы прикручивания GC к C++. Но тут есть одна штука. В C++ по умолчанию ресурсами надо управлять вручную, потому есть определённая вероятность ошибиться и заюзать небезопасные указатели и т.п.

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

R>Забудем на время про память, и рассмотрим все остальные ресурсы — файла, сокеты, соединения с БД, графические хэндлы и всевозможные хэндлы различных библиотек. Программисты на управляемых языках умеют писать программы безопасные по отношению к этим ресурсам?

На безопасных языках возможно реализовать автоматику для любых ресурсов, которые не требуют детерминированного завершения и не являются сверхценными. В твоем примере "графические хэндлы и всевозможные хэндлы различных библиотек" таковыми могут и не являться. Штатно в дотнете подобное управление реализовано для хендлов GDI и USER, причем первые реально никто почти никогда не чистит руками. Тем не менее к проблемам это не приводит.

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

M>Мне кажется у тебя неверная предросылка, о том что С++ програмист управляет памятью.

Ну да, в шарпе проблема явно юзинг указать для детерминированного завершения, а явно использовать смартпоинтеры для любого класса и руками разруливать циклы, это конечно не проблема .

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

K>В других языках зато либо вообще отсутсвует возможность автоматического управления ресурсами (C), либо это делается так, что хочется проклинать и язык, и ресурсы (C++). Д а и что тут "другие"? Языков, требующих GC немало, они не ограничиваются Java/C#. Так вот, при этом ручное управление ресурсами одинаково хорошо реализовано и в С, и в C++, и в C#. Значит, у языков с GC есть некоторое преимущество.

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

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

K>Это тривиальный случай. Вообще, в случае с файлами как правило не приходится сильно извращаться. С памятью бывает полный ППЦ. Например, те же вещи связанные с генерацией ДКА по регулярному выражению. Или задача на ICFP 2007 (интерпретатор генов), которая _оптимально_ в случае с GC решается легко и естественно, а без GC приходится извращаться.
Это не совсем так — там просто нужна структура типа "веревка". На чистом С++ она тоже неплохо делается, причем даже работает вполне быстро

K>Или та, задача, которую я решаю сейчас — выделение из прайс-листов полезной информации и запихивание её в БД. Вот сижу, смотрю на свой код на C#, и думаю: до чего же надо иметь извращённый мозг, чтобы во всей этой трёхэтажной алгоритмике, вовсю нашпигованной эвристикой, ещё и памятью управлять?
В таких задачах, действительно, сборщик мусора вполне нормально подходит.

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

E>А как вы будете все это делать с GC, если все это нужно будет действительно _удалить_, а не оставить в мусоре до следующего прихода GC?
GC.Collect() ?

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

C>Это не совсем так — там просто нужна структура типа "веревка". На чистом С++ она тоже неплохо делается, причем даже работает вполне быстро

Что это за структура?

C>В таких задачах, действительно, сборщик мусора вполне нормально подходит.

Ну вот, всё правильно

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

S>GC.Collect() ?

Тяжеловато, да и, скажем, не гарантируется в Java. ИМХО подход с возможностью и явного, и неявного освобождения логичнее (привет, D), хотя и не без своих проблем.

Здравствуйте, Delight, Вы писали:
D>Тяжеловато, да и, скажем, не гарантируется в Java. ИМХО подход с возможностью и явного, и неявного освобождения логичнее (привет, D), хотя и не без своих проблем.
Как правило, явное освобождение памяти (кроме вырожденных случаев) приносит больше проблем, чем решает.

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

K>Я знаю про всякие мутации смартпоинтеров и про способы прикручивания GC к C++. Но тут есть одна штука. В C++ по умолчанию ресурсами надо управлять вручную, потому есть определённая вероятность ошибиться и заюзать небезопасные указатели и т.п.

Возможность для ошибки существует всегда (с этим странно спорить) . Я коментировал высказывание о том что програмируя на С++ програмист тратит время на управление ресурсами.