Вот можно сколько угодно говорить насколько здорово в Яве сделано управление памятью.
И применять этот код практически всегда java + СУБД
Только вот когда дело касается эффективности, то все эти штучки дрючки на ( ...-машинах )
нервно курят. И разные это вещи каждому свое которые не корректно сравнивать ( С++ компилируемый язык, точка ). Мне нравится когда код работает с максимальной эффективностью очень быстро.
и это не для интерпретаторов на ( ...-машинах )

Аноним 50 пишет:

> Изучаю java и возникают вопросы:
>
> *Зачем нужен сборщик мусора?*
> *Как можно обходиться без деструкторов?*

У вас в голове — каша. Как связаны деструкторы с освобожнением
памяти ? Ответ — никак. Деструктор ДЕИНИЦИАЛИЗИРУЕТ объект,
а не освобождает память. Это можно делать как перед освобождением
памяти, так и без неё. Также никто не запрещает в языке с garbage
collector иметь и вызывать деструкторы, там просто в другом проблема —
в том, чтобы снизить накладные расходы по раскрутке стека.

Так что вы сначала разберитесь с этим.

Конечно вы правы, Java — это заметная деградация по сравнению
с С++, но в этом есть и плюсы — быстрая раскрутка стека и дешёвые
исключения. А так — всё делать руками, конечно, в finally.

...
Закон парных случаев в действии. Только в пятницу об этом думал именно в таких выражениях.

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

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

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

Что бы новый объект на его месте инициализировать =)

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

MZ>Аноним 50 пишет:

>> Изучаю java и возникают вопросы:
>>
>> *Зачем нужен сборщик мусора?*
>> *Как можно обходиться без деструкторов?*

MZ>У вас в голове — каша. Как связаны деструкторы с освобожнением
MZ>памяти ? Ответ — никак.
............
MZ>Так что вы сначала разберитесь с этим.

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


MZ>Конечно вы правы, Java — это заметная деградация по сравнению
MZ>с С++, но в этом есть и плюсы — быстрая раскрутка стека и дешёвые
MZ>исключения. А так — всё делать руками, конечно, в finally.

А>>а зачем деинициализированному объекту память держать? исходим из того что после деинициализации вызов любого метода объекта приведет к ошибке
А>Что бы новый объект на его месте инициализировать =)
А причем тут GC? Обычный heap manager тоже самое делает

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

MZ>У вас в голове — каша. Как связаны деструкторы с освобожнением
MZ>памяти ? Ответ — никак.

В C++ вполне себе связаны. Раскрутка стека, или там зачистка объектов-членов в случае delete, вызывают исполнение деструкторов прямо во внутреннем контексте runtime'а. Что в свою очередь налагает ограничения на содержимое деструкторов, и в итоге исходная проблема не решена.

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

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

Этот уровень создан до меня и является стандартом для любого программиста и не требует никаких усилий.

зы
Много шуму на тему того, что C++ — язык прошлого и т.д. А вот Java — весь такой удобный, и одно удовольствие писать на нем, и освобождает программиста от рутины...
Хотя я думаю иначе(пока что, дальше видно будет).

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

C>Только вот когда дело касается эффективности,

Какой из них ?

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

И Java, и C# — тоже компилируемые языки. Так что действительно точка.
*В смысле вопроса о Вашей полной некомпетентности в области subj'а.

C>Мне нравится когда код работает с максимальной эффективностью очень быстро.

Я так понял, что Вы пишете исключительно в машинных кодах ?

Аноним 373 пишет:

> а зачем деинициализированному объекту память держать? исходим из того
> что после деинициализации вызов любого метода объекта приведет к ошибке
Да господи, да мало ли зачем !
Ну например — чтобы другой аналогичный (или вообще другой) объект в этой
памяти создать.

Аноним 50 пишет:
> Изучаю java и возникают вопросы:

Отвечаем ЧЁТКО на ЧЁТКО ПОСТАВЛЕННЫЕ ВОПРОСЫ. Без демагогий.

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

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

> Ведь, деструкторы соберут весь мусор.

Деструкторы память не освобождают.

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

Использовать finally или другие (в других языках, не в Java)
защитные огороды стека. Это только для С++ программистов кажется
неестественно, потому что они к этому привыкли. Теоретически
написание finally и написание кода в деструкторе — проблемы одного
порядка сложности. Да, в Java это немного хуже, потому что
код в деструкторе надо не забыть написать один раз, а код в
finally — КАЖДЫЙ раз. Но если *тебе так нравится Java*, то тебе
просто ничего не остается делать. Если тебе Java не нравится —
изучай более другие языки программирования (не имею в виду C++
в данном случае, видимо, его ты уже знаешь).

Соберите объектник слинкуйте и запустите хоть где нибудь без Java интерпретатора в кучу мегов
Так что не надо передергивать и всякие там байт коды называть бинарниками ок?

RTFM в общем. учите матчасть!!
точка.

C>>Мне нравится когда код работает с максимальной эффективностью очень быстро.

D>Я так понял, что Вы пишете исключительно в машинных кодах ?

drol пишет:

> В C++ вполне себе связаны. Раскрутка стека, или там зачистка
> объектов-членов в случае delete, вызывают исполнение деструкторов прямо
> во внутреннем контексте runtime'а. Что в свою очередь налагает
> ограничения на содержимое деструкторов, и в итоге исходная проблема не
> решена.

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

MZ>Деструкторы память не освобождают.
Это смотря что написать в деструкторе. Например, деструктор смартпойнтера именно что освобождает память.

MZ>Да, в Java это немного хуже, потому что
MZ>код в деструкторе надо не забыть написать один раз, а код в
MZ>finally — КАЖДЫЙ раз.
Ага. И это кошмар.

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

А>Что бы новый объект на его месте инициализировать =)

Эка у меня номер сегодня злой получился =)))

Vamp пишет:
> MZ>Деструкторы память не освобождают.
> Это смотря что написать в деструкторе. Например, деструктор
> смартпойнтера именно что освобождает память.

Деструктор данного объекта не освобождает память, занимаемую
данным объектом. Он только осуществляет деинициализацию
этого объекта.

> Ага. И это кошмар.
> Да здравствует мыло душистое и веревка пушистая.

Ну им-то нравится !
Вообще, прикольно, что тема эта всплывает именно здесь, в С++.
Жавские пингвины-то даже про это не задумаются обычно.

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

C>Да ну нах, что за чушь.

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

MZ>Использовать finally или другие (в других языках, не в Java)
MZ>защитные огороды стека. Это только для С++ программистов кажется
MZ>неестественно, потому что они к этому привыкли. Теоретически
MZ>написание finally и написание кода в деструкторе — проблемы одного
MZ>порядка сложности.

Не вполне. См. ниже.

MZ>Да, в Java это немного хуже, потому что
MZ>код в деструкторе надо не забыть написать один раз, а код в
MZ>finally — КАЖДЫЙ раз.

И не только это.
* Деструктор инкапсулирует очистку, что само по себе хорошо: не возникает никаких левых внешних и взаимных зависимостей и прочие плюсы инкапсуляции.
* Деструкторы вызываются только для уже сконструированных объектов (т.е. если к моменту выброса исключения какой-то обеъкт еще не создался, то его деструктор не вызовется). В ситуации с finally у тебя один блок на все объекты, а это означает, что придется городить какой-то огород вокруг твоих объектов, чтобы внутри finally понять, у кого звать деструктор, а у кого — нет.
* Порядок вызова деструкторов устанавливается автоматически. В принципе невозможно "забыть" вызвать деструктор или позвать их не в том порядке. В случае с finally придется за всем этим следить руками.

You will always get what you always got
  If you always do  what you always did

MZ>Да господи, да мало ли зачем !
MZ>Ну например — чтобы другой аналогичный (или вообще другой) объект в этой
MZ>памяти создать.
Обычный С++ ный менеджер кучи именно этим занимается — при free часто не отдает память системе, а держит ее на "на будущее". GC тут совершенно не концептуален.