Изучаю java и возникают вопросы:

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


Как можно обходиться без деструкторов?
неужели код

    mutex.lock();//что если обьектов много и какой-то из них забыли закрыть
    try {
        ....
    }
    finally{
        mutex.unlock();
    }

считается удобнее и надежнне чем:

    {
        boost::mutex::lock l(mutex);
        .............
    }

а как быть с очисткой ресурсов (закрытием файлов, различных соединений), тоже руками?
В с++ надо один раз очистить ресурс в деструкторе, а java 30 раз в коде, где этот обьект используется.
Не совсем понятно в чем прелесть такого подхода?

Здравствуйте, Аноним, Вы писали:

А>Зачем нужен сборщик мусора?
А>Ведь, деструкторы соберут весь мусор.
А>Я не помню когда последний раз руками очищал память в с++.

Вы, почему-то, рассматриваете только самый примитивный случай: короткоживущие неизменяемые независимые объекты на стеке. А вот давайте возьмём долгоживущую изменяемую древовидную структуру в heap'е. Например, дерево объектов UI. Насколько простым будет управление памятью для такой штуки в C++ ? Вот в managed средах/языках вообще ничего делать не надо; порождать свои собственные структуры такого вида также элементарно.

А>Как можно обходиться без деструкторов?
А>неужели код
А>считается удобнее и надежнне чем:
А>а как быть с очисткой ресурсов (закрытием файлов, различных соединений), тоже руками?

Java имеет неудобный синтаксис в этом месте. В C# же для таких случаев есть специальная конструкция using. Вариант же из C++ лично мне не нравится отсутствием явного обозначения области жизни ресурса.
*Хотя... Если бы это делала IDE, то было бы достаточно.

А>В с++ надо один раз очистить ресурс в деструкторе,

Теоретически. А на практике, при написании деструктора C++ сразу возникает очень много ограничений. Простейший пример: исключение в деструкторе => до свидания развёртка стека и всё остальное.

А>Не совсем понятно в чем прелесть такого подхода?

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

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

D>Вы, почему-то, рассматриваете только самый примитивный случай: короткоживущие неизменяемые независимые объекты на стеке. А вот давайте возьмём долгоживущую изменяемую древовидную структуру в heap'е. Например, дерево объектов UI. Насколько простым будет управление памятью для такой штуки в C++ ? Вот в managed средах/языках вообще ничего делать не надо; порождать свои собственные структуры такого вида также элементарно.

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

D>Java имеет неудобный синтаксис в этом месте. В C# же для таких случаев есть специальная конструкция using. Вариант же из C++ лично мне не нравится отсутствием явного обозначения области жизни ресурса.
D>*Хотя... Если бы это делала IDE, то было бы достаточно.

А>>В с++ надо один раз очистить ресурс в деструкторе,

D>Теоретически. А на практике, при написании деструктора C++ сразу возникает очень много ограничений. Простейший пример: исключение в деструкторе => до свидания развёртка стека и всё остальное.

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

Здравствуйте, Аноним, Вы писали:

А>Зачем нужен сборщик мусора?

Для решения, в числе прочих, проблемы циклических ссылок. «Умные указатели» могут решить все проблемы, которые решает сборка мусора, кроме проблемы циклических ссылок.

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

Это были преимущества. Недостатки, полагаю, очевидны.

Здравствуйте, Аноним, Вы писали:

D>>Вы, почему-то, рассматриваете только самый примитивный случай: короткоживущие неизменяемые независимые объекты на стеке. А вот давайте возьмём долгоживущую изменяемую древовидную структуру в heap'е. Например, дерево объектов UI. Насколько простым будет управление памятью для такой штуки в C++ ? Вот в managed средах/языках вообще ничего делать не надо; порождать свои собственные структуры такого вида также элементарно.
А>В таких случаях я пользуюсь смарт поинтерами.

Ну вот видите. Вам приходится добавлять целый синтаксический + семантический уровень с соответствующим полным комплектом развлечений. В managed же средах/языках Вы освобождены от этих чисто технических аспектов.

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

Ещё бы. Я тоже старался с ними не сталкиваться во времена работы на C++ А вот на Java/.NET что хочу, то и ворочу

D>>Теоретически. А на практике, при написании деструктора C++ сразу возникает очень много ограничений. Простейший пример: исключение в деструкторе => до свидания развёртка стека и всё остальное.
А>Не могу представить пример где бы логика требовала исключение в деструкторе.

А как вызывающему коду нормально узнать, что при очистке случилась ерунда ?

А>Разумно в деструкторе выполнять действия уничтожающие объекты и соответственно не требующие дополнительных ресурсов.

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

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

D>Ну вот видите. Вам приходится добавлять целый синтаксический + семантический уровень с соответствующим полным комплектом развлечений. В managed же средах/языках Вы освобождены от этих чисто технических аспектов.

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

Здравствуйте, Аноним, Вы писали:

А>Зачем нужен сборщик мусора?
А>Ведь, деструкторы соберут весь мусор.
А>Я не помню когда последний раз руками очищал память в с++.

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

К сожалению, это плохо согласуется с традиционным для C++ подходом, когда создание/уничтожение объекта имеет побочные эффекты (не важно, в виде захвата мутекса, создания базы данных на диске и т.п. Важно, что эти побочнные эффекты видны в программе не через "значение" объекта).

это плохо согласуется не только с С++, но так же с трандиционным подходом в файловых системах, СУБД, указанных автором поста примитивов синхронизации и вообще любых ресурсов с ограниченным количеством пользователей, которые надо ОБЯЗАТЕЛЬНО детерминистически освобождать. Контроль за освобождением памяти это самое простое.

Здравствуйте, Аноним, Вы писали:

А>это плохо согласуется не только с С++, но так же с трандиционным подходом в файловых системах, СУБД, указанных автором поста примитивов синхронизации и вообще любых ресурсов с ограниченным количеством пользователей, которые надо ОБЯЗАТЕЛЬНО детерминистически освобождать. Контроль за освобождением памяти это самое простое.

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

Таких конструктов лучше избегать, они — источники сложных ошибок, причем ошибок не только в коде, но и в архитектуре. Если избежать невозможно, то надо предусмотреть какое-то централизованное управление каждым глобальным рисурсом, с явным и ясным интерфейсом.

Прятать же захват глобального ресурса в конструктор локального объекта, а освобождение в деструктор — далеко не самая светлая идея.

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

D>>Ну вот видите. Вам приходится добавлять целый синтаксический + семантический уровень с соответствующим полным комплектом развлечений. В managed же средах/языках Вы освобождены от этих чисто технических аспектов.

S>Ну почти освобождены только до моментов пока вы считаете, что память бесканечна

Ничего не понял. Причём здесь "бесконечная память" какая-то ???

S> или не уперлись в вызов unmanaged кода.

Совершенно верно, unmanaged-код — наш главный враг
А с managed-кодом всё в полном порядке.

*Singularity/Midori forever!!!

А>>это плохо согласуется не только с С++, но так же с трандиционным подходом в файловых системах, СУБД, указанных автором поста примитивов синхронизации и вообще любых ресурсов с ограниченным количеством пользователей, которые надо ОБЯЗАТЕЛЬНО детерминистически освобождать. Контроль за освобождением памяти это самое простое.

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

Pzz>Таких конструктов лучше избегать, они — источники сложных ошибок, причем ошибок не только в коде, но и в архитектуре. Если избежать невозможно, то надо предусмотреть какое-то централизованное управление каждым глобальным рисурсом, с явным и ясным интерфейсом.
Слишком много слов выше...

Pzz>Прятать же захват глобального ресурса в конструктор локального объекта, а освобождение в деструктор — далеко не самая светлая идея.
Очень удобно я вам скажу. Как раз такие объекты обычно захватываются на недолгое время и концепция автоматических объектов очень удобна оказывается. Но если вы ее не использовали хотябы полгода вам не понять.

Здравствуйте, Аноним, Вы писали:

Pzz>>Прятать же захват глобального ресурса в конструктор локального объекта, а освобождение в деструктор — далеко не самая светлая идея.
А>Очень удобно я вам скажу. Как раз такие объекты обычно захватываются на недолгое время и концепция автоматических объектов очень удобна оказывается. Но если вы ее не использовали хотябы полгода вам не понять.

Очень удобно, знаете ли, решать все вопросы с помощью маузера. Только работает не долго — пока в ногу себе первый раз не выстрелишь.

Pzz>>>Прятать же захват глобального ресурса в конструктор локального объекта, а освобождение в деструктор — далеко не самая светлая идея.
А>>Очень удобно я вам скажу. Как раз такие объекты обычно захватываются на недолгое время и концепция автоматических объектов очень удобна оказывается. Но если вы ее не использовали хотябы полгода вам не понять.

Pzz>Очень удобно, знаете ли, решать все вопросы с помощью маузера. Только работает не долго — пока в ногу себе первый раз не выстрелишь.
Тоже самое можно сказать про любой другой предмет обихода

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

S>>Ну почти освобождены только до моментов пока вы считаете, что память бесканечна

D>Ничего не понял. Причём здесь "бесконечная память" какая-то ???

GC не оптимально расходует память. К примеру, если создал 10 м объектов, но используешь только 100, а остальные уже не надо бы держать в мозгах и их уже можно разрушить, но вся эта куча объектов не может быть удалена автоматически, если неизвесна семантика твоей программы.

Поэтому и получается, что программы на Java столько памяти и кушают.

Здравствуйте, Аноним, Вы писали:

Pzz>>Очень удобно, знаете ли, решать все вопросы с помощью маузера. Только работает не долго — пока в ногу себе первый раз не выстрелишь.
А>Тоже самое можно сказать про любой другой предмет обихода

Ну вы ведь не хотите содержательно вопрос обсуждать — для вас слишком много букв получается

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

S>>>Ну почти освобождены только до моментов пока вы считаете, что память бесканечна
D>>Ничего не понял. Причём здесь "бесконечная память" какая-то ???
S>GC не оптимально расходует память. К примеру, если создал 10 м объектов, но используешь только 100, а остальные уже не надо бы держать в мозгах и их уже можно разрушить,

Продолжаю непонимать. Зачем Вы создали и держите полноценные ссылки на 10М объектов, если используете только 100 ???

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

S>>GC не оптимально расходует память. К примеру, если создал 10 м объектов, но используешь только 100, а остальные уже не надо бы держать в мозгах и их уже можно разрушить,

D>Продолжаю непонимать. Зачем Вы создали и держите полноценные ссылки на 10М объектов, если используете только 100 ???

Мы же говорим о "ленивом" программисте, который пишет не раздумывая над тонкостями аллокации и деаллокации объектов, а именно GC отучает программиста думать о памяти: надо создать объект — создай, а удаление где-то за кадром. А если программист начнет думать о ссылках на объекты и поведении GC, то и вызвать деструктор или создать умный указатель для него больщой проблемы не будет. Вот мы и вернулись к вопросу топика "Зачем нужен сборщик мусора?".

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

D>>Продолжаю непонимать. Зачем Вы создали и держите полноценные ссылки на 10М объектов, если используете только 100 ???
S>Мы же говорим о "ленивом" программисте,

Нет, мы говорим о механизмах распределения памяти.

S>который пишет не раздумывая над тонкостями аллокации и деаллокации объектов,

Неквалифицированный программист пишет ерунду всегда. Хотя соглашусь: в managed-средах вероятность более-менее адекватной работы им написанного всё-таки повыше...

S>а именно GC отучает программиста думать о памяти:

Ерунда. Как и всякая более высокоуровневая система, GC отучает думать о низкоуровневых проблемах, бо они просто отсутствуют.

S>надо создать объект — создай, а удаление где-то за кадром.

Именно так. Надо — создай. А вот "надо 100 — создай 10М" это совершенно из другой оперы.

S>А если программист начнет думать о ссылках на объекты и поведении GC,

Квалифицированный программист думает об этом, бо знает какие ошибки распределения памяти бывают в managed-средах.

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

Для квалифицированного — не будет. Для него также не будет проблемой всё это и на ассемблере написать. Вопрос только во времени: вместо ковыряния с регистрами/деструкторами лучше позаниматься чем-нибудь полезным...

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

S>GC не оптимально расходует память. К примеру, если создал 10 м объектов, но используешь только 100, а остальные уже не надо бы держать в мозгах и их уже можно разрушить, но вся эта куча объектов не может быть удалена автоматически, если неизвесна семантика твоей программы.

S>Поэтому и получается, что программы на Java столько памяти и кушают.

Я не производил аккуратных замеров, но по ощущениям программы на яве кушают заметно больше памяти, чем программы, скажем, на питоне. И тот и другой языки используют GC. И вообще, когда GC был придуман (в LISP'е, в конце 50-х) , столько памяти даже представить себе было нельзя. Так что в пожирании памяти все же не GC сам ои себе виноват, а чьи-то кривые рученки

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

Pzz>Так что в пожирании памяти все же не GC сам ои себе виноват, а чьи-то кривые рученки

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