Помогите с ООП - страница 4

Новый комментарий
 
Vasiliy Sokolov #:

Официально как бы да. Неофициально, многие штуки свидетельствуют что он все-таки есть:

  • В MQL нет указателей. Вместо них используется нечто, что очень их напоминает. 
  • В MQL нет прямого выделения памяти как в Си например;
  • Программы на MQL исполняет некая виртуальная машина. Об этом Ренат писал вскольз и неидиножды;
  • Можно определить экземляр класса, который будет освобожден автоматически. Значит есть какой-то механизм, который следит за этими экземплярами и освобождает их при необходимости. Что это, если не сборщик мусора?
  • Любые экземпляры, инициализированые через указатель, и не освобожденные должным образом, будут помечены как leaked objects при выходе из программы. Будет напечатано их количество и общий размер потерянной памяти. Программа с утечками памяти даже не пройдет валидацию в Маркете. Следовательно все объекты, даже выделяемые вручную, учтены, известны и о них знает система. Это одна из классических задач, которые решает сборщик мусора.

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

 
Dmitry Fedoseev #:

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

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

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

Мне очень не нравится ситуация в языках, где new есть, а delete - не требуется, мол, "система уберет ненужное". Это не только может потенциально снижать эффективность работы (когда ненужные объекты еще не удалены), но и расхолаживает кодера, позволяя ему не следить за последствиями своих действий. 

 
Georgiy Merts #:

Мне очень не нравится ситуация в языках, где new есть, а delete - не требуется, мол, "система уберет ненужное". Это не только может потенциально снижать эффективность работы (когда ненужные объекты еще не удалены), но и расхолаживает кодера, позволяя ему не следить за последствиями своих действий. 

Производительность наоборот в общем случае повышается. Ручное удаление требует нехилого времени в основном потоке. + удаление происходит по элементно. Сравните две версии скрипта например в этом топике. Разница в с корости в несколько раз. Эффективность по памяти также увеличивается. Потому что сборщик мусора перемещает объекты уплотняя их друг с другом. При ручном управлении, образуются свободные дыры в памяти, которые уже не так просто использовать повторно. Плюс сборщик работает в другом потоке. Основное время не тратится. В общем одни плюсы.

 
Vasiliy Sokolov #:

Производительность наоборот в общем случае повышается. Ручное удаление требует нехилого времени в основном потоке. + удаление происходит по элементно. Сравните две версии скрипта например в этом топике. Разница в с корости в несколько раз. Эффективность по памяти также увеличивается. Потому что сборщик мусора перемещает объекты уплотняя их друг с другом. При ручном управлении, образуются свободные дыры в памяти, которые уже не так просто использовать повторно. Плюс сборщик работает в другом потоке. Основное время не тратится. В общем одни плюсы.

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

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

Только в этом случае он будет называться сборщиком мусора. Те два скрипта - из другой оперы. Божий дар с яичницей не надо путать. 

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

 
Georgiy Merts #:

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

///

Этот наверно тот "сборщик", который дает сообщение об утечке памяти по завершению работы.

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

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

новые объекты? Программа будет неработоспособной, памяти не хватит.

Настоящий сборщик удаляет потерянные объекты в процессе работы программы, а не

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

можно при любых условиях и в любом количестве плодить объекты.

 
Vasiliy Sokolov #:

Производительность наоборот в общем случае повышается. Ручное удаление требует нехилого времени в основном потоке. + удаление происходит по элементно. Сравните две версии скрипта например в этом топике. Разница в с корости в несколько раз. Эффективность по памяти также увеличивается. Потому что сборщик мусора перемещает объекты уплотняя их друг с другом. При ручном управлении, образуются свободные дыры в памяти, которые уже не так просто использовать повторно. Плюс сборщик работает в другом потоке. Основное время не тратится. В общем одни плюсы.

Хм... А в сборщике мусора удаление непоэлементно? Не говоря уж о том, что другой поток, когда нет свободных ядер - осуществляется силами того же ядра, и замедляет основной поток. 

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

Потому мне сборщик и не нравится, что поощряет этот самый наплевательское обращение с ресурсами. 

 
Dmitry Fedoseev #:

Этот наверно тот "сборщик", который дает сообщение об утечке памяти по завершению работы.

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

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

новые объекты? Программа будет неработоспособной, памяти не хватит.

Настоящий сборщик удаляет потерянные объекты в процессе работы программы, а не

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

можно при любых условиях и в любом количестве плодить объекты.

Все верно. Потому мне работа со сборщиком и не нравится - пользователь перестает обращать внимание, сколько он объектов наплодил, и где.

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

 
Dmitry Fedoseev #:

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

Дмитрий, извините, вы хоть один язык программирования знаете кроме мукля? Нет, не знаете. И работать с объектами и указателями до сих пор не научились, - это ясно по тем немногим кодам и даже статьям, что вами опубликованы. Поэтому я даже не могу серьезно что-то ответить на этот бездарный и откровенно глупый комментарий. Ну почитайте наконец википедию что ли, почитайте что такое сборщик мусора и как он устроен, почитайте хоть раз наконец то, на что пытаетесь ссылаться. Пока же, это все выглядит как лай собаки на караван: бессмысленный и беспощадный.
 
Georgiy Merts #:

Хм... А в сборщике мусора удаление непоэлементно? Не говоря уж о том, что другой поток, когда нет свободных ядер - осуществляется силами того же ядра, и замедляет основной поток. 

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

Потому мне сборщик и не нравится, что поощряет этот самый наплевательское обращение с ресурсами. 

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

 
Vasiliy Sokolov #:

сравните скорости автоматического удаления объектов и ручного.

Желательно сразу ответ. На эксперименты не всегда есть время.

123456789
Новый комментарий