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

AVK>>>А где он применяется где он нафик не нужен?

S>>Ну например в игрушках.

WF>Мменя поглючило или в Ил-2 java использовалась? Я там вроде какие-то классы видел, JVM.

Вот про Ил-2 я как раз и говорил Там AI на java написан. В связи с чем иногда наблюдается такой прикол: заходишь на цель, враги разбегаются, их AI жутко напрягается, что вызывает сборку мусора. В результате сборки мусора (пара секунд) имеем лежащие на земле горящие обломки самолета Хотя может я и ошибаюсь и это не GC виноват.

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

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

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

AVK>> Сбои могут привести к тому что где то смартпоинтер не сможет декрементировать счетчик ссылок и самое страшное что такая ситуация фатальна — никакими способами отловить это и исправить ситуацию нет.

S>>А что, уже есть распределенные реализации GC?

AVK>Есть, лизинг называется.

url?

S>>Причем в которых при пересечении объектом границ между машинами для уничтожения объекта используется именно GC, а не подсчет ссылок?

AVK>Именно GC-подобный алгоритм. Никаких счетчиков ссылок.

Т.е., сервер сканирует все адресное пространство всех клиентов и ищет там свои адреса? Или все-таки ведется отдельная таблица всех внешних ссылок?

S>>Дык извини, они так же (или в большей степени) будут подвержены воздействию ошибок, как и подсчет ссылок.

AVK>Да вот как раз нет, любой сбой в итоге приведет к недосягаемости того кто ссылается и GC тут же пришибет такие объекты.

А если сбой случится именно во время работы GC? За здорово живешь прибъется нужный объект?

AVK>> Ну и остается проблема циклических ссылок, которая тоже смартпоинтерами не решается.

S>>Сильные/слабые ссылки + переопределение оператора new вполне помогают.

AVK>Это все больше и больше гемороя. Уже смартпоинтеры это увеличение объема ручной работы. Причем ты никак не застрахован от того что смартпоинтер будут использовать неверно или вобще не будут использовать.

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

AVK>А уж ручное распределение куда воткнуть слабую ссылку совсем не фонтан.

Это как?

AVK>>Но не стоит наверное по тому что такие ситуации тебе встречаются редко делать окончательный вывод о применимости технологии, согласен? Мне вот например встречаются часто.

S>>Цитату, пожалуйста — где я говорю о том, что GC неприменим нигде.
AVK>

M>>Пока один программист — понятно. Как только появляются несколько (например, компонент используется внешней программой), возникают вопросы.

AVK>Которые прекрасно решаются и без GC. Хотя с GC, безусловно, для их решения приходится предпринимать несколько меньше усилий.

AVK>...

M>>Есть разные методы борьбы, и GC на сегодняшний момент — один из лучших.

AVK>Я бы сказал, один из самых ресурсоемких.

AVK>Заметь, не некоторые, не иногда. А именно все задачи использования компонент внешней программой прекрасно решаются без GC.

Решаются, разумеется. Иногда с большими усилиями, чаще — не очень.

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

Обойтись без GC можно не практически всегда, а вообще всегда. Иногда — малой кровью, иногда — большой.
По крайней мере, до появления Java GC оставался в области академических изысков.

AVK>а те мелкие удобства которые он дает перекрываются его выдающейся ресурсоемкостью.

Чаще — перекрываются, иногда — нет. Но, опять же, про то, что GC неприменим нигде, я не говорил. Тебе не приходило в голову, что целесообразность применения какого-то средства для решения задачи и принципиальная возможность решения задачи без этого средства — разные вещи?

AVK>>А где он применяется где он нафик не нужен?

S>>Ну например в игрушках.

AVK>Много видел игрушек на дотнете? Я пока ни одной, если не считать сапера, который я сам же написал и его порта под WinCE.

А при чем здесь дотнет? Я про GC говорил, дотнет сам по себе меня не интересует.

AVK>>Опять же ты правильно заметил — все зависит от конкретной задачи. Иногда производительность не является самым главным фактором. По секрету могу сказать что заваленных из-за недостаточной производительности проектов мне видеть не приходилось, а вот заваленных из-за огромного количества багов, недостаточной гибкости и функциональности, неудобной архитектуры я видел море.

S>>А при чем здесь недостаточная гибкость, функциональность и неудобная архитектура?

AVK>Да все при том. Куча рутинной работы, вроде написания и использования смартпоинтеров со слабыми ссылками или беклогом удобству и скорости разработки не способствуют.

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

AVK>>Поэтому мне вполне понятно движение в сторону улучшения цикла разработки, пусть даже в ущерб перфомансу.

S>>Мне тоже, кстати. Но применение GC сильно усложняет разработку в том случае, если есть критичные по быстродействию части.

AVK>Вот как то за 2 с лишним года программирования сначала под джаву, а потом под дотнет я что то особо не страдал.

Ты писал на дотнете критичные к скорости исполнения вещи? Или ты делал это на джаве?

AVK>Зато перед этим на дельфях страдал от утечек регулярно.

Странно, я при работе на С++ с утечками памяти сталкиваюсь не чаще раза в несколько месяцев. И локализую их достаточно быстро.

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

S>Обойтись без GC можно не практически всегда, а вообще всегда. Иногда — малой кровью, иногда — большой.
S>По крайней мере, до появления Java GC оставался в области академических изысков.

Не согласен . Есть вещи, после переписывания которых без GC поменяются (причем скорее всего) принципы их работы и структура.

Java JFC Swing. Переписать, наверное, можно. Только получится уже не то.



Хотя это смотря с какой точностью смотреть. На уровне Asm-а и WinApi, напрмер, никакого GC нет... А любая прога под Винды в результате в это и вырождается...

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

AVK>Ну и дальше? При чем тут Дельфи?
Ну как, можно отключить проверку рантайм-ошибок, не ловить исключения, никогда не закрывать за собой файлы и SQL-соединения, а пользователей научить кнопке reset, благо положить NTFS тяжело )
Ты будешь рыдать, но таких приложений на Delphi я видел N+1. К нам они попадают как раз в тот момент, когда главный архитектор оригинального проекта уходит создавать свою контору, а остатки IT-отдела умудряются добавлять не более одной фичи в месяц. И вот тогда наступает время нанять русских.

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

S>Не может. При таких сбоях, в результате которых не вызываются деструкторы смартпойнтеров, приложение просто не выживет.

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

AVK>Есть, лизинг называется.

S>url?

MSDN

AVK>Именно GC-подобный алгоритм. Никаких счетчиков ссылок.

S>Т.е., сервер сканирует все адресное пространство всех клиентов и ищет там свои адреса? Или все-таки ведется отдельная таблица всех внешних ссылок?

Есть такая штука как спонсоры. Подробности в MSDN.

AVK>Да вот как раз нет, любой сбой в итоге приведет к недосягаемости того кто ссылается и GC тут же пришибет такие объекты.

S>А если сбой случится именно во время работы GC? За здорово живешь прибъется нужный объект?

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

S>Неверное использование исключить можно почти всегда,

Сказки это все. Если можно что то сделать не так как надо, это обязательно сделают.

AVK>А уж ручное распределение куда воткнуть слабую ссылку совсем не фонтан.

S>Это как?

Это так. Все эти алгоритмы отслеживания циклов, если их выполнять для всех смартпоинтеров, приводят к тому что производительность становится хуже производительности GC. Ранние реализации GC в джаве здесь уже в качестве примера приводили. Единсвенный способ добиться приемлемой производительности — программисту указывать хинты в тех местах где могут встретиться циклические ссылки.

S>Решаются, разумеется. Иногда с большими усилиями, чаще — не очень.

Вот о том и речь что я не согласен с тем что чаще всего GC не нужен.

AVK>а те мелкие удобства которые он дает перекрываются его выдающейся ресурсоемкостью.

S>Чаще — перекрываются, иногда — нет.

То есть, следуя твоей логике, оказывается что GC практически никогда не нужен. Что и требовалось доказать.

S>Но, опять же, про то, что GC неприменим нигде, я не говорил.

Ну хорошо, пусть будет как правило неприменим. Это мало что меняет.

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

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

S>А связи между количеством рутиной работы и неудобной архитектурой я все равно не вижу.

Одна из главных задач архитектуры приложения — снижение количества рутинной работы.

AVK>Вот как то за 2 с лишним года программирования сначала под джаву, а потом под дотнет я что то особо не страдал.

S>Ты писал на дотнете критичные к скорости исполнения вещи? Или ты делал это на джаве?

Серверные приложения являются критичными к скорости исполнения? А десктоп-клиенты, вроде почтовых являются?

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

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

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

S>>Не может. При таких сбоях, в результате которых не вызываются деструкторы смартпойнтеров, приложение просто не выживет.

AVK>Ну это ты зря. Если произошел сбой в потоке, обслуживающем клиента, его можно просто пришибить. В этом случае GC все равно весь мусор приберет, а вот смартпоинтеры так и останутся незакрытыми.

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

AVK>>Именно GC-подобный алгоритм. Никаких счетчиков ссылок.

S>>Т.е., сервер сканирует все адресное пространство всех клиентов и ищет там свои адреса? Или все-таки ведется отдельная таблица всех внешних ссылок?

AVK>Есть такая штука как спонсоры. Подробности в MSDN.

"The lease manager maintains a lease list with leases sorted by remaining lease time" "The lease manager maintains a list of the sponsors (they implement the ISponsor interface) stored in order of decreasing sponsorship time." Я примерно об этом и говорил — список ссылок. То же самое запросто делается на смартпойнтерах без GC — какая разница, как убивать объекты по ссылкам из листа — гарбадж коллектором или вызовом release.

AVK>>Да вот как раз нет, любой сбой в итоге приведет к недосягаемости того кто ссылается и GC тут же пришибет такие объекты.

S>>А если сбой случится именно во время работы GC? За здорово живешь прибъется нужный объект?

AVK>Вероятность сбоя самого GC значительно меньше, поскольку код не пользовательский, да и выполняется нечасто. В любом случае, даже если GC сбойнет, то он таки все почистит при следующем запуске.

Давай-ка сначала договоримся, про какие сбои мы говорим — про сбои коммуникаций или ошибки в программе? Я так понял, начал говорить ты именно про ошибки коммуникаций — иначе при чем здесь распределенные системы?

S>>Неверное использование исключить можно почти всегда,

AVK>Сказки это все. Если можно что то сделать не так как надо, это обязательно сделают.

Если бы это всегда соответствовало действительности, ни одна работоспособная программа не была бы до сих пор написана Больше возможностей, больше и ответственность — по-другому не бывает. А запретить неправильное использование класса и смартпойнтера для него иногда (не всегда, к сожалению) очень просто: приватные конструктор и деструктор, смартпойнтер нужного типа объявляется другом.


AVK>Это так. Все эти алгоритмы отслеживания циклов, если их выполнять для всех смартпоинтеров, приводят к тому что производительность становится хуже производительности GC. Ранние реализации GC в джаве здесь уже в качестве примера приводили. Единсвенный способ добиться приемлемой производительности — программисту указывать хинты в тех местах где могут встретиться циклические ссылки.

Теперь понятно. Да, программисту придется использовать для слабых ссылок один класс, для сильных — другой.

S>>Решаются, разумеется. Иногда с большими усилиями, чаще — не очень.

AVK>Вот о том и речь что я не согласен с тем что чаще всего GC не нужен.

Ну, это действительно зависит от того, что ты чаще всего делаешь.


AVK>То есть, следуя твоей логике, оказывается что GC практически никогда не нужен. Что и требовалось доказать.

Не то чтобы практически никогда, но очень часто — не нужен.

S>>Но, опять же, про то, что GC неприменим нигде, я не говорил.

AVK>Ну хорошо, пусть будет как правило неприменим. Это мало что меняет.

Довольно многое, на мой взгляд.

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

AVK>Да собственно и явный вызов деструктора тоже дело привычки и в общем то не напрягает.

Это разные вещи. Принципиально разные. Одно дело писать autoref_ptr<Object> obj(new Object) вместо Object* obj = new Object, и совсем другое — отслеживать, где объект перестал быть нужен.

AVK>Вот только почему то утечки памяти явление не такое уж и редкое даже у опытных программистов.

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


S>>А связи между количеством рутиной работы и неудобной архитектурой я все равно не вижу.

AVK>Одна из главных задач архитектуры приложения — снижение количества рутинной работы.

Но не наоборот Уменьшение количества рутиной работы вовсе не означает автоматического улучшения архитектуры.


AVK>Серверные приложения являются критичными к скорости исполнения?

Не всегда. Часто самым узким местом у них является внешняя БД, и хоть ты свое серверное приложение до последней строчки обоптимизируй — ощутимо быстрее оно не станет.

AVK>А десктоп-клиенты, вроде почтовых являются?

Mail и news клиенты, естественно, не являются критичными ни к скорости работы, ни к объему пожираемой памяти — если они пишутся для современного писишного железа.

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

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

Да обычные совершенно задачки. Но действительно, чаще все намного печальнее.

M>Например, в Дельфи можно при желании забивать на освобождение объектов:

AVK>Ну и дальше? При чем тут Дельфи?

При том, что Дельфи работает без GC. Те же самые удобства для программиста и без GC достижимы, на AddRef/Release

AVK>Есть такая штука как спонсоры. Подробности в MSDN.

S>"The lease manager maintains a lease list with leases sorted by remaining lease time" "The lease manager maintains a list of the sponsors (they implement the ISponsor interface) stored in order of decreasing sponsorship time." Я примерно об этом и говорил — список ссылок. То же самое запросто делается на смартпойнтерах без GC — какая разница, как убивать объекты по ссылкам из листа — гарбадж коллектором или вызовом release.

Точно! В случае с внешними клиентами AddRef/Release и GC пользуются одинаковой стратегией.

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

S>Ах вон ты про что. В результате такой ситуации запросто может получиться, что клиент что-то куда-то записал только на половину, объекты, порожденные в этом потоке имеют неправильное состояние и породят еще один сбой в коде финализации при сборке мусора и т.п.

Неверный вывод. Все неуправляемые ресурсы должны оборачиваться try .. finally, все управляемые ресурсы прибьются гарантированно в любом состоянии.

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

Не глупо а насущная необходимость.

S>"The lease manager maintains a lease list with leases sorted by remaining lease time" "The lease manager maintains a list of the sponsors (they implement the ISponsor interface) stored in order of decreasing sponsorship time." Я примерно об этом и говорил — список ссылок. То же самое запросто делается на смартпойнтерах без GC — какая разница, как убивать объекты по ссылкам из листа — гарбадж коллектором или вызовом release.

Разница в причинах. Список ссылок управляется целиком и полностью сервером, а для смартпоинтеров такой список будет управляться клиентом.

AVK>Вероятность сбоя самого GC значительно меньше, поскольку код не пользовательский, да и выполняется нечасто. В любом случае, даже если GC сбойнет, то он таки все почистит при следующем запуске.

S>Давай-ка сначала договоримся, про какие сбои мы говорим — про сбои коммуникаций или ошибки в программе? Я так понял, начал говорить ты именно про ошибки коммуникаций — иначе при чем здесь распределенные системы?

И ошибки и сбои коммуникаций.

AVK>Сказки это все. Если можно что то сделать не так как надо, это обязательно сделают.

S>Если бы это всегда соответствовало действительности, ни одна работоспособная программа не была бы до сих пор написана

Тем не менее куча умерших из-за наличия трудноисправимых ошибок проектов существует.

S>Теперь понятно. Да, программисту придется использовать для слабых ссылок один класс, для сильных — другой.

А это вери бед дизайн, поскольку мы навешиваем свои проблемы на программера.

AVK>То есть, следуя твоей логике, оказывается что GC практически никогда не нужен. Что и требовалось доказать.

S>Не то чтобы практически никогда, но очень часто — не нужен.

Вот с этим я и не согласен.

AVK>Ну хорошо, пусть будет как правило неприменим. Это мало что меняет.

S>Довольно многое, на мой взгляд.

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

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

AVK>Да собственно и явный вызов деструктора тоже дело привычки и в общем то не напрягает.

S>Это разные вещи. Принципиально разные. Одно дело писать autoref_ptr<Object> obj(new Object) вместо Object* obj = new Object, и совсем другое — отслеживать, где объект перестал быть нужен.

Вот только не все так просто. Все это катит если смартпоинтер можно разместить на стеке. Тогда компилер позаботится о вызове его деструктора. А если время жизни объекта больше области видимости? А? Таким же манером нужно явно вызывать деструктор смартпоинтера.

AVK>Вот только почему то утечки памяти явление не такое уж и редкое даже у опытных программистов.

S>Вредные привычки долго умирают, это да. Ну а GC в этом плане всего лишь заменяет утечки памяти на утечки хэндлов.

Каких хендлов? Ты о чем?

S>>А связи между количеством рутиной работы и неудобной архитектурой я все равно не вижу.

AVK>Одна из главных задач архитектуры приложения — снижение количества рутинной работы.

S>Но не наоборот Уменьшение количества рутиной работы вовсе не означает автоматического улучшения архитектуры.

Зато увеличение количества рутинной работы точно свидетельствует о недостатках архитектуры. Так есть связь?

AVK>Серверные приложения являются критичными к скорости исполнения?

S>Не всегда. Часто самым узким местом у них является внешняя БД, и хоть ты свое серверное приложение до последней строчки обоптимизируй — ощутимо быстрее оно не станет.

AVK>А десктоп-клиенты, вроде почтовых являются?

S>Mail и news клиенты, естественно, не являются критичными ни к скорости работы, ни к объему пожираемой памяти — если они пишутся для современного писишного железа.

Так что же тогда из часто встречающихся задач критично к скорости выполнения?

S>Да обычные совершенно задачки.

Какие?

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

M>Точно! В случае с внешними клиентами AddRef/Release и GC пользуются одинаковой стратегией.

Стратегия принципиально разная. Если клиент не вызовет Release то все, полный писец.

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

M>Например, в Дельфи можно при желании забивать на освобождение объектов:

AVK>Ну и дальше? При чем тут Дельфи?

M>При том, что Дельфи работает без GC. Те же самые удобства для программиста и без GC достижимы, на AddRef/Release

Чего? Ты о каких таких AddRef в дельфях? Если ты создал объект в Дельфях то ты его должен грохнуть, никто за тебя это не сделает. Исключение составляют только ссылки на СОМ объекты. Твой код приведет к утечкам.

M>При том, что Дельфи работает без GC. Те же самые удобства для программиста и без GC достижимы, на AddRef/Release

AVK>Чего? Ты о каких таких AddRef в дельфях? Если ты создал объект в Дельфях то ты его должен грохнуть, никто за тебя это не сделает. Исключение составляют только ссылки на СОМ объекты. Твой код приведет к утечкам.

Исключение составляют интерфейсы, которые всегда работают по AddRef/Release, включая COM-объекты. Мой код не приведёт к утечкам.

M>Точно! В случае с внешними клиентами AddRef/Release и GC пользуются одинаковой стратегией.

AVK>Стратегия принципиально разная. Если клиент не вызовет Release то все, полный писец.

Даже в DCOM есть какие-то дополнительные механизмы для этих случаев. Слышал я, что там некое "пингование" происходит, кода по сети работают. Это пример.


А стратегия-то одна: хранить список внешних ссылок, и периодически проверять их жизнеспособность. В принципе, тот же AddRef/Release, только доделанный.

Интерестно, есть ли в природе более гладкие и остроумные стратегии на этот счёт? Пулы какие-нибудь — это старо и неостроумно.

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

S>>Ах вон ты про что. В результате такой ситуации запросто может получиться, что клиент что-то куда-то записал только на половину, объекты, порожденные в этом потоке имеют неправильное состояние и породят еще один сбой в коде финализации при сборке мусора и т.п.

AVK>Неверный вывод. Все неуправляемые ресурсы должны оборачиваться try .. finally, все управляемые ресурсы прибьются гарантированно в любом состоянии.

Ты не видишь разницы между ресурсами и состоянием объекта, которое в результате ошибки будет inconsistent?

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

AVK>Не глупо а насущная необходимость.

Насущная необходимость — писать программы, которые вычисляют незнамо что? Гы

S>>"The lease manager maintains a lease list with leases sorted by remaining lease time" "The lease manager maintains a list of the sponsors (they implement the ISponsor interface) stored in order of decreasing sponsorship time." Я примерно об этом и говорил — список ссылок. То же самое запросто делается на смартпойнтерах без GC — какая разница, как убивать объекты по ссылкам из листа — гарбадж коллектором или вызовом release.

AVK>Разница в причинах. Список ссылок управляется целиком и полностью сервером, а для смартпоинтеров такой список будет управляться клиентом.

Ага, щаз. Кем захочу, тем и будет управляться. Клиентом оно будет управляться только если я решу одноуровневой схемой смартпойнтеров обойтись.

AVK>>Вероятность сбоя самого GC значительно меньше, поскольку код не пользовательский, да и выполняется нечасто. В любом случае, даже если GC сбойнет, то он таки все почистит при следующем запуске.

S>>Давай-ка сначала договоримся, про какие сбои мы говорим — про сбои коммуникаций или ошибки в программе? Я так понял, начал говорить ты именно про ошибки коммуникаций — иначе при чем здесь распределенные системы?

AVK>И ошибки и сбои коммуникаций.

Тогда причем здесь сбои GC и пользовательского кода?


AVK>Тем не менее куча умерших из-за наличия трудноисправимых ошибок проектов существует.

Подобные проекты с GC просто еще не успели появится, не то что умереть

S>>Теперь понятно. Да, программисту придется использовать для слабых ссылок один класс, для сильных — другой.

AVK>А это вери бед дизайн, поскольку мы навешиваем свои проблемы на программера.

Угу, а вызывать руками Dispose при наличии циклических ссылок — вери гуд дизайн и никакой головной боли, да?

AVK>>Ну хорошо, пусть будет как правило неприменим. Это мало что меняет.

S>>Довольно многое, на мой взгляд.

AVK>А по моему ничего. Малоприменимость технологии переводит ее в разряд ненужных.

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

S>>Это разные вещи. Принципиально разные. Одно дело писать autoref_ptr<Object> obj(new Object) вместо Object* obj = new Object, и совсем другое — отслеживать, где объект перестал быть нужен.

AVK>Вот только не все так просто. Все это катит если смартпоинтер можно разместить на стеке.

Или сделать членом класса

AVK>Тогда компилер позаботится о вызове его деструктора. А если время жизни объекта больше области видимости?

А ничего страшного. Если объект нужен, где-то в программе будут находящиеся внутри какой-нибудь области видимости объект (смартпойнтер, если мы не хотим неприятностей), ссылающийся на экземпляр Object. Когда этот смартпойнтер создавался, он увеличил счетчик ссылок мастер-пойнтера на Object (скрытого в данном случае от программиста — его создает autoref_ptr при конструировании на основе raw-указателя).
GC, кстати, тоже считает нужными только те объекты, адрес которых встретился на стеке, в регистрах или его внутренних таблицах (в которые объект заносится, чтобы предотвратить его уничтожение при взаимодействии со внешним миром), и те обекты, на которые они прямо или косвенно ссылаются.

AVK>А? Таким же манером нужно явно вызывать деструктор смартпоинтера.

Ужас какой

S>>Вредные привычки долго умирают, это да. Ну а GC в этом плане всего лишь заменяет утечки памяти на утечки хэндлов.

AVK>Каких хендлов? Ты о чем?

О ресурсах.

S>>Но не наоборот Уменьшение количества рутиной работы вовсе не означает автоматического улучшения архитектуры.

AVK>Зато увеличение количества рутинной работы точно свидетельствует о недостатках архитектуры. Так есть связь?

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

AVK>Так что же тогда из часто встречающихся задач критично к скорости выполнения?

Да много чего. В общем-то, определяется это конкретными требованиями, а не принадлежностью софта к какому-либо классу. Какая разница сервер или клиент, главное — будет оно тормозить или нет, если тот код, что ты пишешь, замедлить/ускорить, и заметит ли эти тормоза кто-нибудь.
А так, часто критична по быстродействию 2D-3D графика, кое-какая мультимедия, иногда — парсинг текстов, движки баз данных, сервера, расчитанные на риалтайм использование большим количеством клиентов, иногда — вычислительная математика, некоторые игры, "умный" GUI — да всего и не перечислить.

S>>Да обычные совершенно задачки.

AVK>Какие?

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

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

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

AVK>Не глупо а насущная необходимость.

S>Насущная необходимость — писать программы, которые вычисляют незнамо что? Гы

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

AVK>Разница в причинах. Список ссылок управляется целиком и полностью сервером, а для смартпоинтеров такой список будет управляться клиентом.

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

Только если убрать зависимость от действий клиента то как раз GC и получится, тока геморою в 10 раз больше.

S>>Давай-ка сначала договоримся, про какие сбои мы говорим — про сбои коммуникаций или ошибки в программе? Я так понял, начал говорить ты именно про ошибки коммуникаций — иначе при чем здесь распределенные системы?

AVK>И ошибки и сбои коммуникаций.

S>Тогда причем здесь сбои GC и пользовательского кода?

При том что возможность этих сбоев надо учитывать.


AVK>Тем не менее куча умерших из-за наличия трудноисправимых ошибок проектов существует.

S>Подобные проекты с GC просто еще не успели появится, не то что умереть

Про джаву забыл?

AVK>А по моему ничего. Малоприменимость технологии переводит ее в разряд ненужных.

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

Ок, ненужна в универсальном средстве разработок, я правильно формулирую твою мысль?

S>А ничего страшного. Если объект нужен, где-то в программе будут находящиеся внутри какой-нибудь области видимости объект (смартпойнтер, если мы не хотим неприятностей), ссылающийся на экземпляр Object. Когда этот смартпойнтер создавался, он увеличил счетчик ссылок мастер-пойнтера на Object (скрытого в данном случае от программиста — его создает autoref_ptr при конструировании на основе raw-указателя).

Ты перечитай что ты написал и подумай. А потом сравни с GC.

AVK>А? Таким же манером нужно явно вызывать деструктор смартпоинтера.

S>Ужас какой

Не ужас, но потенциальный источник глюков.

S>>Вредные привычки долго умирают, это да. Ну а GC в этом плане всего лишь заменяет утечки памяти на утечки хэндлов.

AVK>Каких хендлов? Ты о чем?

S>О ресурсах.

С чего это вдруг ты о них вспомнил?

S>>Но не наоборот Уменьшение количества рутиной работы вовсе не означает автоматического улучшения архитектуры.

AVK>Зато увеличение количества рутинной работы точно свидетельствует о недостатках архитектуры. Так есть связь?

S>Прямой связи нет. Увеличение количества рутинной работы может происходить по самым разным причинам, не только из-за недостатков архитектуры.

А я и не писал что связь прямая.

S>А так, часто критична по быстродействию 2D-3D графика, кое-какая мультимедия, иногда — парсинг текстов, движки баз данных, сервера, расчитанные на риалтайм использование большим количеством клиентов, иногда — вычислительная математика, некоторые игры, "умный" GUI — да всего и не перечислить.

Вот вот, о том и речь. Сразу тебе скажу — для этих областей дотнет в общем то и не создавался. Так же как не создавался для реалтайм задач к примеру. Никто ведь не возмущается что в багажник мерса мало кирпичей входит.

AVK>Какие?

S>Ну, на моем нынешнем месте работы — GUI (почти весь спектр, от "формочек" до визуализации весьма объемных данных), кой-какая вычислительная математика в клиент-серверном исполнении, кой-кая работа с базами данных.

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

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

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

M>Исключение составляют интерфейсы, которые всегда работают по AddRef/Release, включая COM-объекты. Мой код не приведёт к утечкам.

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

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

S>>Насущная необходимость — писать программы, которые вычисляют незнамо что? Гы

AVK>Насущная необходимость застраховываться от ситуаций, которые изначально были непредусмотрены.

Тут вопрос, что в конкретном случае важнее — живучесть программы или достоверность данных. Получается — GC повышает живучесть программы за счет снижения достоверности данных и снижения детерменированности поведения.

AVK>>Разница в причинах. Список ссылок управляется целиком и полностью сервером, а для смартпоинтеров такой список будет управляться клиентом.

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

AVK>Только если убрать зависимость от действий клиента то как раз GC и получится, тока геморою в 10 раз больше.

Во-первых, это не GC. Во-вторых, решение с GC менее гибкое.

AVK>>Тем не менее куча умерших из-за наличия трудноисправимых ошибок проектов существует.

S>>Подобные проекты с GC просто еще не успели появится, не то что умереть

AVK>Про джаву забыл?

Смайлик заметил? Ты процент умерших сравни, от общего числа проектов, а не абсолютное количество.


AVK>>А по моему ничего. Малоприменимость технологии переводит ее в разряд ненужных.

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

AVK>Ок, ненужна в универсальном средстве разработок, я правильно формулирую твою мысль?

Неправильно. В универсальном средстве разработки GC не повредит, но — как опция, а не как безальтернативный способ работы с памятью.

S>>А ничего страшного. Если объект нужен, где-то в программе будут находящиеся внутри какой-нибудь области видимости объект (смартпойнтер, если мы не хотим неприятностей), ссылающийся на экземпляр Object. Когда этот смартпойнтер создавался, он увеличил счетчик ссылок мастер-пойнтера на Object (скрытого в данном случае от программиста — его создает autoref_ptr при конструировании на основе raw-указателя).

AVK>Ты перечитай что ты написал и подумай. А потом сравни с GC.

Поясни, о чем ты?

AVK>>А? Таким же манером нужно явно вызывать деструктор смартпоинтера.

S>>Ужас какой

AVK>Не ужас, но потенциальный источник глюков.

Естественно, поэтому так никто не делает.

S>>>Вредные привычки долго умирают, это да. Ну а GC в этом плане всего лишь заменяет утечки памяти на утечки хэндлов.

AVK>>Каких хендлов? Ты о чем?

S>>О ресурсах.

AVK>С чего это вдруг ты о них вспомнил?

Потому что это вполне реальная проблема, более "вредная", чем утечки памяти.

S>>А так, часто критична по быстродействию 2D-3D графика, кое-какая мультимедия, иногда — парсинг текстов, движки баз данных, сервера, расчитанные на риалтайм использование большим количеством клиентов, иногда — вычислительная математика, некоторые игры, "умный" GUI — да всего и не перечислить.

AVK>Вот вот, о том и речь. Сразу тебе скажу — для этих областей дотнет в общем то и не создавался. Так же как не создавался для реалтайм задач к примеру. Никто ведь не возмущается что в багажник мерса мало кирпичей входит.

Т.е., приличный гуй на нем не сделать?

S>>Ну, на моем нынешнем месте работы — GUI (почти весь спектр, от "формочек" до визуализации весьма объемных данных), кой-какая вычислительная математика в клиент-серверном исполнении, кой-кая работа с базами данных.

AVK>И ты рассказываешь о том как важно быстродействие? В гуях?

Угу. Попробуй pie-chart изобразить, у которого подписи к долькам пирога друг на друга не налазят — сразу поймешь, нужно там быстродействие или нет. Bin packing задачи и Point feature labeling problem в гуях возникают постоянно.

AVK>По моему это не та задача где можно много выиграть, ручками управляя памятью.

Расположение узлов графов — вполне подходящий тому пример.

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

AVK>В общем дисскусия вырождается в обычный флейм, новые аргументы я уже не вижу, одно перетирание всем известных фактов. Я наверное продолжать не буду.

Ну и не продолжай.

AVK>Во первых по твоему коду совершенно непонятно что речь идет об интерфейсах,

Должно быть понятно. IMyObject — что это ещё может быть за тип, конечно интерфейс. Тем более это становится понятно, когда увидеть, что этому объекту присваивается TMyObject.Create.


AVK> во вторых интерфесы в Дельфи таки добавили как раз для поддержки кома.

Ввели для поддержки, а теперь уже используют не только (в седьмой версии особенно!) Очень уж удобная вещь оказалась.


Кстати, пример приводился как иллюстрация GC vs AddRef/Release. Для программиста преимуществ в удобстве записи GC не даёт.

Здравствуйте, unprogrammer, Вы писали:
<...>
U>Borland последние десять лет только и пытается отнять кусочек у Microsoft. Своих идей, своих мыслей, а тем более долгосрочных планов у них нет. Все что они делают — это лишь попытка хоть что нибудь противопоставить. Но видимо в последнее время силенок то стало не хватать — вот тебе и пожалуйста интеграция с .NET. А то обычно бы они начали делать свой .COM, .WEB, что нибудь еще.

ЗДря Вы так Борланд не любите.
Он один реально продвинул платформу Java в корпоративный сектор (в J2EE по большей части его идеи воплощены). JBuilder — лучшая среда для разработки корпоративного софта на Java. Кстати, основные доходы (более 60%) — рынок Java-решений, а отнюдь не Win. J2EE-сервер BES — лучший в своём классе (масштабируемость, кластеризуемость, многоплатформенность).
Delphi — это так, пустяк, чтобы быть откусить мааленький кусочек ОГРОМНОГО пирога Win-решений.

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

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

NN>Ты знаешь, нет,не думал. Что касается скорости и удобства разработки интерфейса, .Net далеко до С++ Бильдера или Дельфей, с которого он собственно и слизан . Если в бильдере делать статические экзешники, без VCL, то они получаются здоровые, но все-таки не 10 метров.
NN>Да и вообще у меня под VC6 уже скопился удобный набор open-source библиотек,интерфейс получается не хуже, а немного кода ручками мне сильно не мешает Большая часть времени уходит не на разработку мордочек, а на обработку данных, а визуализация у меня преимущественно своя — 1) кривые 2)карты-поверхности 3)таблицы просмотра больших массивов данных ( по 2-5 Мб на столбец таблицы). Стандартных компонент, которые работали бы с приемлимой скоростью и делали то что надо, я не видел

NN>Другое дело, что масштабиремость и переносимость, но тут тоже анекдот — "Ваша программа будет работать везде... где установлен Windows..." — так она и так работает...
NN>В общем дело ясное что дело темное.
NN>Что будет дальше, я не знаю, но пока из всего вышепрописанного могу сделать вывод:

NN> ЕСЛИ НАДО СДЕЛАТЬ ЧТО-ТО ОТЛИЧНОЕ ОТ ТЕКСТОВОГО РЕДАКТОРА ИЛИ ПРОГРАММЫ СОСТАВЛЕНИЯ АНКЕТ, .Net НИЗАЧЕМ НЕ НУЖЕН


Вы знаете, уважаемый, вы исходите из логики "если мне сейчас хорошо, то мне будет хорошо всегда". Либы для плюсов у вас есть гуйные? А то, что в дотнете как раз именно ручками этот самый гуй разрабатывать в разы проще вы не задумывались? А этот спор — что откуда слизано? Ясное дело, если человеку нравится дельфи (как например, mihailik), то он будет всячески отпираться от того, что этот самый дельфи слизан с VB.
Хотя VB был первой визуальной средой разработки, а визуальность — не последнее "ключевое" слово в дельфи. А если человек любит VB, так для него, извините, и весь дотнет с него слизан (в чем, кстати сказать, есть малая толика правды).
Значит, теперь к вопросу, откуда слизан дотнет. Что там? Жаба, дельфи, билдер, васька...? Мне вот лично вообще пофигу откуда он слизан. Какая собственно разница? В виде дотнета я получаю хорошую визуальную среду разработку, обладающую огромной гибкостью благодаря сериализации в код, удобство до-диеза и прежнюю старую добрую мощность плюсов — все это сгодится не только для того, чтобы писать текстовые редакторы или программы составления анкет. И, кстати, народ в дотнете уже вовсю пишет. Так что не надо здесь прописными буквами прописные истины писать. Если вы сами в дотнете ничего другого сделать не можете, то это уж, извините, ваша проблема.