ну и?

Ну, я за первый вариант.  

Второе.  

Lazin, у тебя появилось новое рабочее место? 

А вообще - зависит от задачи. Для прикладных приложений - само собой полноценный GC нужен, для системного девелопмента - само собой вручную...

Добавлено через 42 секунды
PS Не голосовал

  Я за выбор. Т.е. чтобы его можно было включать/выключать. Вообще, мне кажется что приложение должно потреблять ресурсы настолько насколько оно полезно, а задержки по выполнению могут должны быть предсказуемы. С другой стороны во многих случаях освобождение памяти усложняет программу, и требует излишнего контроля, как следствие место для потенциальных ошибок. Но тупо использовать всегда и везде считаю неэффективным. Есть разные стратегии управления памятью, например один  владелец, остальные пользователи. Владелец освобождает память. Или же все имеют равные права, освобождаем как только никому не нужен. Или же некая связная группа, которая должна уничтожаться целиком. Уничтожение объекта связанно с освобождением всех ресурсов, не только памяти, тут же на лицо имеем искусственное разделение. Память отдельно, прочие ресурсы отдельно. Это нелогично.

почему, и для каких именно приложений?

неа

  

Логично. В высокоуровневых современных языках, рантайм которых основан на ВМ, управлять памятью вручную очень нерационально. В том числе с точки зрения скорости работы. GC достаточно продуманный механизм. Ну а так - всякие Marshal.GlobalAlloc и пр. никто не отменял..

  Одно другому не мешает. Если я явно говорю удали, то оно должно удалиться. Зачем мне ждать пока прога скушает 100 Мб и после этого начнет чесаться о памяти? У меня может быть связанная группа объектов, для ее разруливания не нужно много мозгов, нужно просто взять и освободить. Я например захочу сделать для нее некий пул. Только для этой группы. Когда понадобиться я тупо возьму освобожу всю память одним махом и попутно освобожу внешние ресурсы. 
  На крайний случай я бы хотел иметь возможность создавать несколько таких сборщиков с разными настройками управления памятью.

уточню, под выбором, я имею ввиду самостоятельную реализацию механизма управления памятью, например смарт-поинтеры в С++, а не тотальное включение/выключение GC для всей программы


вот именно, скорее всего, твой код работает с объектами, а не с участками памяти

а если где-то, один из пользователей, переживет владельца? В данном случае, у тебя время жизни "пользователей" зависит от времени жизни "владельца", это дополнительная зависимость внутри приложения, которая усложняет код. Особенно весело, пытаться обеспечить эти условия в многопоточном приложении.

здесь нужно что-то вроде подсчета ссылок, а это то-же далеко не бесплатно, к тому-же могут возникнуть циклические зависимости

очень даже логично, ты знаком с концепцией аллокаторов в STL?
память может быть повторно использована, либо, участок памяти может не принадлежать какому-то одному объекту

Добавлено через 6 минут и 37 секунд

ну, удаление объекта != освобождение памяти, если твоя программа работает под управлением современной ВМ, то создание удаление объектов - очень дешево, намного дешевле чем выделение - освобождение памяти в куче


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

Ну.. Вообщем-то я уже говорил - никто не мешает использовать интероп-методы. Это раз. Второе - есть C++/CLI. Сорри за привязку к дотнету - я говорю про суть.

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


Собственно главная проблема классических "идеальных" смарт-поинтеров в С++ - это именно производительность. Они жутко медлены. По сравнению с полноценным GC.

Добавлено через 7 минут и 11 секунд
Ах, да - думать о памяти приходится, хотя и крайне редко и при наличии GC. Если мы знаем, что собираемся выполнить операцию, которой может понадобится дофига памяти (какие-нибудь глобальные маппинги там хравнить, например, придётся) - то можно явно запустить сборку мусора перед этой операцией. Чтобы сама операция была, условно говоря, непрерывной. Но опять-таки (как всегда) думать об это заранее - явно не стоит..

А ещё приходится явно вызывать релиз каждого COM-объекта, при использовании OLE-автоматизации на server-side. Но это минус .Net VM, а не объективная необходимость.

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

+1

GC не занимается ни в коем случае постоянным подсчётом ссылок. Подсчёт производится, но только когда это нужно. Основываясь на том, что информация обо всех объектах (о стеке, о статическех филдах и т. д.) доступна для ВМ.

  Я этого не говорил. Речь шла об определении времени жизни объекта с многими владельцами. Эту стратегию отлично закрывает GC, не в пример SharedPtr. Вот только памяти все это жрет...

GC? По сравнению с чем?