Помогите с ООП - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Официально как бы да. Неофициально, многие штуки свидетельствуют что он все-таки есть:
Есть один достаточный и исчерпывающий признак того, что сборщика мусора в эмкуле нет - после new обязателен delete.
Есть один достаточный и исчерпывающий признак того, что сборщика мусора в эмкуле нет - после new обязателен delete.
Насколько я помню, кто-то из разработчиков признал, что сборщик мусора, таки, есть. Но для пользователя его "как бы нет".
Ну а насчет пары new-delete - я категорически ЗА. В общем случае за запрошенные ресурсы должны отвечать те объекты, которые эти ресурсы запросили. Есть исключения типа "фабрики объектов" - но там специально предполагается, что ответственность за созданные объекты ложится на того, кто эти объекты у фабрики запросил.
Мне очень не нравится ситуация в языках, где new есть, а delete - не требуется, мол, "система уберет ненужное". Это не только может потенциально снижать эффективность работы (когда ненужные объекты еще не удалены), но и расхолаживает кодера, позволяя ему не следить за последствиями своих действий.
Мне очень не нравится ситуация в языках, где new есть, а delete - не требуется, мол, "система уберет ненужное". Это не только может потенциально снижать эффективность работы (когда ненужные объекты еще не удалены), но и расхолаживает кодера, позволяя ему не следить за последствиями своих действий.
Производительность наоборот в общем случае повышается. Ручное удаление требует нехилого времени в основном потоке. + удаление происходит по элементно. Сравните две версии скрипта например в этом топике. Разница в с корости в несколько раз. Эффективность по памяти также увеличивается. Потому что сборщик мусора перемещает объекты уплотняя их друг с другом. При ручном управлении, образуются свободные дыры в памяти, которые уже не так просто использовать повторно. Плюс сборщик работает в другом потоке. Основное время не тратится. В общем одни плюсы.
Производительность наоборот в общем случае повышается. Ручное удаление требует нехилого времени в основном потоке. + удаление происходит по элементно. Сравните две версии скрипта например в этом топике. Разница в с корости в несколько раз. Эффективность по памяти также увеличивается. Потому что сборщик мусора перемещает объекты уплотняя их друг с другом. При ручном управлении, образуются свободные дыры в памяти, которые уже не так просто использовать повторно. Плюс сборщик работает в другом потоке. Основное время не тратится. В общем одни плюсы.
Василий, извините, но вы вообще не понимаете ничего в том, о чем сейчас пытаетесь рассуждать. Вообще ничего и никак.
Википедию хоть почитайте, что такое сборщик мусора. Основная его особенность в том, что он удаляет объекты, связь с которыми потеряна.
Только в этом случае он будет называться сборщиком мусора. Те два скрипта - из другой оперы. Божий дар с яичницей не надо путать.
И с чего вдруг от сборщика повысится производительность? Это еще одна прокладка между полезным кодом и железом, причем не слабая такая прокладочка.
Насколько я помню, кто-то из разработчиков признал, что сборщик мусора, таки, есть. Но для пользователя его "как бы нет".
///
Этот наверно тот "сборщик", который дает сообщение об утечке памяти по завершению работы.
Возможно он даже удаляет оставленные объекты. Но даже если он их удаляет, есть большая
разница - он их удаляет только по завершению работы. А если в многотысячном цикле создавать
новые объекты? Программа будет неработоспособной, памяти не хватит.
Настоящий сборщик удаляет потерянные объекты в процессе работы программы, а не
только по ее завершению. Поэтому допустим такой особый стиль программирования, когда
можно при любых условиях и в любом количестве плодить объекты.
Производительность наоборот в общем случае повышается. Ручное удаление требует нехилого времени в основном потоке. + удаление происходит по элементно. Сравните две версии скрипта например в этом топике. Разница в с корости в несколько раз. Эффективность по памяти также увеличивается. Потому что сборщик мусора перемещает объекты уплотняя их друг с другом. При ручном управлении, образуются свободные дыры в памяти, которые уже не так просто использовать повторно. Плюс сборщик работает в другом потоке. Основное время не тратится. В общем одни плюсы.
Хм... А в сборщике мусора удаление непоэлементно? Не говоря уж о том, что другой поток, когда нет свободных ядер - осуществляется силами того же ядра, и замедляет основной поток.
На мой взгляд, в общем случае, при внимательном подходе, удаление мусора пользователем всегда эффективнее удаления сборщиком. Однако, при наплевательском подходе, безусловно, сборщик мусора выигрывает.
Потому мне сборщик и не нравится, что поощряет этот самый наплевательское обращение с ресурсами.
Этот наверно тот "сборщик", который дает сообщение об утечке памяти по завершению работы.
Возможно он даже удаляет оставленные объекты. Но даже если он их удаляет, есть большая
разница - он их удаляет только по завершению работы. А если в многотысячном цикле создавать
новые объекты? Программа будет неработоспособной, памяти не хватит.
Настоящий сборщик удаляет потерянные объекты в процессе работы программы, а не
только по ее завершению. Поэтому допустим такой особый стиль программирования, когда
можно при любых условиях и в любом количестве плодить объекты.
Все верно. Потому мне работа со сборщиком и не нравится - пользователь перестает обращать внимание, сколько он объектов наплодил, и где.
В принципе, где-то даже упрощается разработка - не надо помнить об удалении занятого. Сборщик сам определит момент, когда на объект уже никто не ссылается, и сам его удалит. Но, мне такая позиция претит. Именно благодаря этой позиции мы имеем программы, которые работают все медленнее и медленнее, которым надо все более и более мощные аппаратные ресурсы на сходные по сложности задачи.
Василий, извините, но вы вообще не понимаете ничего в том, о чем сейчас пытаетесь рассуждать. Вообще ничего и никак.
Хм... А в сборщике мусора удаление непоэлементно? Не говоря уж о том, что другой поток, когда нет свободных ядер - осуществляется силами того же ядра, и замедляет основной поток.
На мой взгляд, в общем случае, при внимательном подходе, удаление мусора пользователем всегда эффективнее удаления сборщиком. Однако, при наплевательском подходе, безусловно, сборщик мусора выигрывает.
Потому мне сборщик и не нравится, что поощряет этот самый наплевательское обращение с ресурсами.
Чем делать предположения, о том как работает сборщик, просто сравните скорости автоматического удаления объектов и ручного. Все фантазии сразу улетучатся.
сравните скорости автоматического удаления объектов и ручного.
Желательно сразу ответ. На эксперименты не всегда есть время.