Здравствуйте, Sergey J. A., Вы писали:
SJA>Здравствуйте, S.Yu.Gubanov, Вы писали:
Ael>>>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.
Ael>>>Спасибо!
SYG>>А противоположную по смыслу ссылку не желаете?
SJA>Давай. Кто-нибудь да пожелает. Я например.... 
А далеко ходить и не надо, вон прямо в соседней ветке...
Короче, .NET Framework или Java отличаются от обычного С++ тем, что там есть сборщик мусора. А сборщик мусора является необходимым условием для написания модульных программ. На обычном С++ модульные программы писать невозможно.
http://www.rsdn.ru/Forum/Message.aspx?mid=725451&only=1Автор: S.Yu.Gubanov
Дата: 19.07.04
SYG>Теперь, собственно, при чем тут сборщик мусора. Рассмотрим более общую ситуацию. Пусть есть многомодульная система. Большинство модулей на момент написания не имели никакого представления друг о друге. Модули — единицы компиляции и исполнения программы, они могут динамически загружаться/выгружаться во время работы Программы. Под Программой, можно понимать всю операционную систему, а модули — ее расширения. Модули создают внутри себя объекты и в виде полиморфных переменных передают их для использования другим модулям, те модули, в свою очередь, могут передать эти полиморфные переменные третьим модулям и т.д.. Модуль создавший обьект и отдавший его другому модулю в принципе понятия не имеет кто еще пользуется этим объектом и как долго он это намерен делать. А значит модуль-создатель в принципе не может нести ответсвенность за уничтожение им созданного объекта. Но никакой другой модуль тоже в принципе не может нести ответсвенность за уничтожение чужого объекта. Подсчет ссылок на объект проблемы не решает поскольку, в общем случае, возможны замкнутые петли (циклические) ссылки объектов друг на друга. Утечка памяти в многомодульных системах неизбежна по принципиально неразрешимым причинам. Единственным выходом из этой ситуации является наличие единого на всю операционную систему полноценного сборщика мусора. Сборщик мусора — это не роскошь, и не фича придуманная для ленивых программистов. Сборщик мусора — это осознанная необходимость. Существование многомодульныех систем, модули которых обмениваются друг с другом объектами, невозможно без одного на всех полноценного сборщика мусора.
http://www.rsdn.ru/Forum/Message.aspx?mid=735774&only=1Автор: S.Yu.Gubanov
Дата: 26.07.04
SYG>Объясняю еще раз. Вот представьте себе что у Вас есть тысяча динамически загружаемых бинарных модулей все от разных производителей. Модули в процессе своей работы создают объекты (каждый модуль создает свои объекты). Для взаимодействия друг с другом эта тысяча модулей обмениваются друг с другом объектами (в виде полиморфных переменных). Объекты могут ссылаться друг на друга произвольным способом (то есть возможны циклические ссылки объектов из разных модулей друг на друга). КТО и КОГДА по Вашему должен вызывать delete для ненужных больше объектов? КАК узнать что объект больше никем не используется? Счетчик ссылок для этих целей не подходит так как возможны петлевые взаимоссылки. Учтите еще что на момент написания модуля НЕИЗВЕСТНО сколько и каких модулей еще будет в той ОС в которой он будет работать. Ну что? Дошло до Вас что задача вызова delete НЕРАЗРЕШИМА на момент написания модуля? Задача освобождения ресурсов может быть решена только ДИНАМИЧЕСКИ во время работы программы, а такая динамическая штуковина называется — СБОРЩИК МУСОРА.
http://www.rsdn.ru/Forum/Message.aspx?mid=737312&only=1Автор: S.Yu.Gubanov
Дата: 27.07.04
SYG>Как организована ваша приватная внутримодульная утилизация более не используемых ресурсов — Ваше личное дело и оно не интересует другие модули (можете даже использовать для этого ту ссылку которую привели). Вопрос состоит в другом — как Вы будете принимать решение об уничтожении объектов адреса которых Вы сообщали другим (внешним) модулям?
SYG>В той ссылке описывается доморощенный сборщик мусора работающий только внутри одного модуля. То есть если запустить два экземпляра такой программы, то, соответственно, будет два доморощенных сборщика мусора. Две таких программы не смогут обмениваться объектами друг с другом. Я же говорю об одном единственном на всю ОС сборщике мусора который единолично разруливает все объекты всех модулей системы. В Component Pascal, .NET и Java сборщик мусора всего один на всю систему независимо от того сколько программ (модулей) в этой системе в данный момент загружено. Так понятно?
