Re[7]: Зачем нужен сборщик мусора? Как жить без деструкторов
От: drol  
Дата: 04.08.08 21:01
Оценка: +3
Здравствуйте, Vamp, Вы писали:

D>>Ну так и что Вы пишете на C++ в этом случае ?

V>Напишу соответствующий код.

Дык напишите, что Вы стесняетесь

*Так страшненько получается ? А если три вложенных ресурса ?

D>>Да ну... Например, если файловый дескриптор на самом деле указывает на сетевой ресурс, то во-первых и сбой возможен, а во-вторых нормальная информация о сбое вполне себе реально необходима.

V>Ну и какое же там восстановление возможно? Вот стала у вас система раком и fclose возвращает ошибку. Что делать будете?

Что захочу, то и буду делать. Могу сразу повторить всю операцию, могу поместить запрос на операцию в очередь с приоритетом/уменьшенным таймаутом, могу спросить пользователя "чего делать", могу просто залогировать событие так как мне надо и т.д.

А вот Вы ничего не сможете сделать, бо даже не узнаете о проблеме...
Re[4]: Зачем нужен сборщик мусора? Как жить без деструкторов
От: drol  
Дата: 04.08.08 21:13
Оценка:
Здравствуйте, Анатолий Широков, Вы писали:

АШ>Есть разница, все же, между catch(...) и finally.


Конечно есть.

АШ>catch(...) — я перехватываю все исключения и делаю это сознательно, finally — я попадаю сюда в независимости от того, было ли исключение или нет.


Извиняйте, а кто finally-то написал ? Дед Мороз ? Вы же и написали. И какая Вам нужна была логика, такую и реализовали.

АШ>Так вот, попав в finally по причине исключения я, выбросил SecondExpection, ввожу пользователя в заблуждение, поскольку он получит наведенное исключение, а не первопричину.


Ну так Вы сами себе (и пользователям) злой Буратино. Одно только непонятно, почему бескомпромиссный terminate() Вы считаете более лучшим исходом...
Re[7]: Зачем нужен сборщик мусора? Как жить без деструкторов
От: drol  
Дата: 04.08.08 21:34
Оценка: +1
Здравствуйте, Аноним, Вы писали:

D>>Да ну... Например, если файловый дескриптор на самом деле указывает на сетевой ресурс, то во-первых и сбой возможен, а во-вторых нормальная информация о сбое вполне себе реально необходима.


А>Кто мешает использовать в этом случае обработчики завершения?


Используйте. Получится код а-ля Java, только хуже, бо finally нема.

D>>Итого:


D>>Подход с деструкторами-очистителями в C++ очень сильно ограничен, и нормально покрывает только самые простые (и по-большей части чисто технические) случаи, типа каких-нибудь smart pointer'ов. Любая очистка требующая новых ресурсов/допускающая отказы, сразу же вызывает тот жуткий код, который Вы напишете в ответ на вопрос из 1-го абзаца


А>Так этих "самых простых" случаев — 95%,


В C++ — 95%, бо на smart pointer'ах сидите всяких. А в Java этих случаев 0%, так как никакие припрыгивания с ссылками не нужны.

А> в оставшихся 5-ти используйте обработчики завершения, блоки try catch


См. выше.

А>Java

А>ужасно выглядит!

Да, проблема имеет место быть, в том числе и поэтому, лично я, давно перебрался на .NET
На C# ботва выглядит гораздо симпатичней:

using(var r1 = new R1())
using(var r2 = new R2())
using(var r3 = new R3())
{
   // чего-то делаем
}


А>В с++ в случаях удовлетворяющих идиоме RAII можно использовать деструкторы,


"Ваша доля — 1 лира" (с) адвокат Терезини
Re[9]: Зачем нужен сборщик мусора? Как жить без деструкторов
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.08.08 23:42
Оценка: +1
Здравствуйте, shrecher, Вы писали:

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


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


Обратите внимание, что вумные указатели требуют инкремента счетчика каждый раз, когда вы его значение куда-нибудь передаете, и декремента с проверкой каждый раз, когда оно уже больше не нужно. Причем чтобы работало на SMP-машинке, операции со счетчиком должны быть с memory barrier'ом, что тоже не уменьшает overhead.

С другой стороны, в несколько более высокоуровневых языках, чем C++ (при условии, что компилятор немного больше понимает, что происходит в программе), overhead от GC может случаться только когда кончается память, да и то не во всех случаях.

Поэтому при наличии соответствующей языковой поддержки, система с GC может оказаться даже эффективнее, чем полуручное управления памятью с помощью умных указателей.
Re[6]: Зачем нужен сборщик мусора? Как жить без деструкторов
От: Юрий Жмеренецкий ICQ 380412032
Дата: 05.08.08 00:01
Оценка: 6 (3) +1 -2
Здравствуйте, drol, Вы писали:
...
D>И вместо того чтобы дёргать какие-то там деструкторы вне нормального контекста исполнения программы (как поступает C++), managed-языки и -среды предоставляют набор вполне удобных механизмов — try/catch/finally/using — для нормального детерминированного управления объектом.
Где-то я все это уже слышал...

//  C++ 
func() 
{ 
   class_with_possible_ressource  cwpr; 
   dosomethingwith(cwpr); 
} 

//  Java 
func() 
{ 
  class_with_possible_ressource  cwpr = new class_with_possible_ressource; 
  if (cwpr->did_initialise_properly()) 
  { 
     try 
     { 
       dosomethingwith(cwpr); 
     } 
     finally 
     { 
        try 
        { 
           idisp = (IDisposable)cwpr; 
           idisp->Dispose(); 
        } 
        catch (...) 
        { 
        } 
     } 
  } 
}


So the Java func above is as easy to understand as the C++-one?? Come
on — you do not really mean that. Also you have a huge problem writing
generic code in Java .... those ugly and presumably costly runtime
checks have to be made all the time.
(с)peter koch

On Java and C++ comp.lang.java.programmer
Re[6]: Зачем нужен сборщик мусора? Как жить без деструкторов
От: landerhigh Пират  
Дата: 05.08.08 01:42
Оценка:
Здравствуйте, drol, Вы писали:

D>Наоборот! Надо делать так, чтобы не приходилось думать о такой ерунде.

D>Например, не надо думать о приоритете и порядке исполнения операций в выражении, надо совершенно тупо и без всякого думанья всегда ставить скобки. И тогда SMS-центр не будет лежать все выходные, от того что уставший и задёрганный к концу рабочего дня пятницы (не будем тыкать пальцем ) уже не мог думать какой приоритет у операции "меньше"...
Безотносительно языка программирования, нужно писать юнит-тесты. Чтобы не уповать на среду, на синтаксис и скобки и чтобы ничего не лежало из-за того, что кто-то прошляпил приоритет операций.
Re[6]: Зачем нужен сборщик мусора? Как жить без деструкторов
От: MasterZiv СССР  
Дата: 05.08.08 05:31
Оценка: 3 (1) +1
drol пишет:

> MZ>Да думать надо, когда пишешь.

>
> Наоборот! Надо делать так, чтобы *не приходилось думать о такой ерунде*.
>
> Например, *не надо думать* о приоритете и порядке исполнения операций в
> выражении, надо совершенно тупо и без всякого думанья *всегда ставить
> скобки*. И тогда SMS-центр не будет лежать все выходные, от того что

Для того, чтобы не надо было думать, это всё должно быть в языке, а не
в каком-то редакторе. У редактора нет ни спецификации, ни стандарта,
есть только надежда, что он как-то поможет.

Но я бы даже сказал больше, что не думать вообще очень вредно.
НАДО ДУМАТЬ ! И надо иметь красивый сложный и мощный язык.

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

Я думаю, что тему надо прекратить, агитировать С++-ников за то,
какая хорошая Java — бессмысленно, а на изначально поставленные
вопросы уже ответили.
Posted via RSDN NNTP Server 2.1 beta
Re[10]: Зачем нужен сборщик мусора? Как жить без деструкторо
От: Danchik Украина  
Дата: 05.08.08 05:41
Оценка: :))) :))
Здравствуйте, Pzz, Вы писали:

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


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


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


Pzz>Обратите внимание, что вумные указатели требуют инкремента счетчика каждый раз, когда вы его значение куда-нибудь передаете, и декремента с проверкой каждый раз, когда оно уже больше не нужно. Причем чтобы работало на SMP-машинке, операции со счетчиком должны быть с memory barrier'ом, что тоже не уменьшает overhead.


Pzz>С другой стороны, в несколько более высокоуровневых языках, чем C++ (при условии, что компилятор немного больше понимает, что происходит в программе), overhead от GC может случаться только когда кончается память, да и то не во всех случаях.


Pzz>Поэтому при наличии соответствующей языковой поддержки, система с GC может оказаться даже эффективнее, чем полуручное управления памятью с помощью умных указателей.


Что то я сомневаюсь что managed языки не используют подсчет ссылок для определения свободен ли обьект или нет для освобождения через GC. Есть другие мнения?
Re[10]: Зачем нужен сборщик мусора? Как жить без деструкторо
От: shrecher  
Дата: 05.08.08 06:58
Оценка: -1
Здравствуйте, Pzz, Вы писали:


Pzz>Причем чтобы работало на SMP-машинке, операции со счетчиком должны быть с memory barrier'ом, что тоже не уменьшает overhead.


Для этого используется обычный InterlockedDecrement, который реализован аппаратно через префикс lock для декремнта:

lock dec eax


В итоге, операции со счетчиком ссылок занимают пару ассемблерных инструкций.
Re[11]: Зачем нужен сборщик мусора? Как жить без деструкторо
От: CreatorCray  
Дата: 05.08.08 07:29
Оценка:
Здравствуйте, shrecher, Вы писали:

S>Для этого используется обычный InterlockedDecrement, который реализован аппаратно через префикс lock для декремнта:


S>
S>lock dec eax
S>

Сильно!

int InterlockedDecrement (int *value)
{
    __asm
    {
        mov    ecx, DWORD ptr [value]
        mov    eax, -1
        lock xadd DWORD ptr [ecx],eax
        dec    eax
    }
}
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[12]: Зачем нужен сборщик мусора? Как жить без деструкторо
От: shrecher  
Дата: 05.08.08 07:41
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC> Сильно!


Не понял, что вас так сильно развеселило?
Re[13]: Зачем нужен сборщик мусора? Как жить без деструкторо
От: CreatorCray  
Дата: 05.08.08 08:15
Оценка:
Здравствуйте, shrecher, Вы писали:

S>Не понял, что вас так сильно развеселило?

то, что залоченная операция проводится с регистром а не с памятью.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[14]: Зачем нужен сборщик мусора? Как жить без деструкторо
От: shrecher  
Дата: 05.08.08 08:28
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


S>>Не понял, что вас так сильно развеселило?

CC>то, что залоченная операция проводится с регистром а не с памятью.

Это к вопросу не относится. На самом деле, я хотел сказать, что overhead от memory barrier и подщета счетчика ссылок минимальный.
Re[15]: Зачем нужен сборщик мусора? Как жить без деструкторо
От: CreatorCray  
Дата: 05.08.08 10:28
Оценка:
Здравствуйте, shrecher, Вы писали:

S>я хотел сказать, что overhead от memory barrier и подщета счетчика ссылок минимальный.

Оверхед от барьера на самом деле относительно существенный.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[11]: Зачем нужен сборщик мусора? Как жить без деструкторо
От: nikov США http://www.linkedin.com/in/nikov
Дата: 05.08.08 12:34
Оценка:
Здравствуйте, Danchik, Вы писали:

D>Что то я сомневаюсь что managed языки не используют подсчет ссылок для определения свободен ли обьект или нет для освобождения через GC. Есть другие мнения?


.NET не использует подсчет ссылок. Он строит граф достижимых объектов, остальные автоматически умирают при дефрагментации.
Re[7]: Зачем нужен сборщик мусора? Как жить без деструкторов
От: SE Украина  
Дата: 05.08.08 13:18
Оценка:
Здравствуйте, shrecher, Вы писали:

Прошу прощения, но пара замечаний из мира .NET

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


Семантика тут не при чем. В дотнете GC работает следующим образом: нет больше ссылок на объект (включая и стек комманд, замечу), всё — объект готов к удалению сборщиком мусора.

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


Про джава судить не могу, в дотнете в некоторох очень специфических случаях джиттер может дооптимизироваться до того, что "уберет" объект даже еще до вызова метода этого объекта.

Про деструкторы. В той же спецификации С# так прямо и написано — по возможности не используйте деструкторы.
Re[7]: Зачем нужен сборщик мусора? Как жить без деструкторов
От: drol  
Дата: 05.08.08 13:19
Оценка: 1 (1) +2 -1
Здравствуйте, landerhigh, Вы писали:

L>Безотносительно языка программирования, нужно писать юнит-тесты.


Относительно-относительно. Писать unit-тесты для C++ — тот ещё экстрим. Reflection'а нет, невозможен нормальный mock'инг, всё копи-пастом, да жуткими макросами всякими, с нулевым maintainability в результате.

L>Чтобы не уповать на среду, на синтаксис и скобки и чтобы ничего не лежало из-за того,


Уповать не надо ни на что. Однако все, всё и вся в разработке должны помогать избегать ошибок. И язык, и IDE, и unit-тесты, и своя голова, и коллеги, и QA. И чем больше таких возможностей предоставляют нижние уровни иерархии, тем меньше проблем всплывёт в "день "Ч".

L>что кто-то прошляпил приоритет операций.


Пример же с приоритетами показывает, что элементарное поведение позволяет полностью ликвидировать целый класс ошибок ещё на самом первом уровне. И, что не менее важно, с нулевыми затратами на "думанье".
Re[13]: Зачем нужен сборщик мусора? Как жить без деструкторо
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.08 15:01
Оценка:
C>Да ну нах, что за чушь.
C>Соберите объектник слинкуйте и запустите хоть где нибудь без Java интерпретатора в кучу мегов
C>Так что не надо передергивать и всякие там байт коды называть бинарниками ок?

соберите объектник и запустите его где-нибдь без mcvcrt*.dll, crt.dll и прочих


dmitriid.comGitHubLinkedIn
Re[7]: Зачем нужен сборщик мусора? Как жить без деструкторов
От: Mamut Швеция http://dmitriid.com
Дата: 05.08.08 15:10
Оценка: +1
ЮЖ>Где-то я все это уже слышал...
ЮЖ>

ЮЖ>//  C++ 
ЮЖ>func() 
ЮЖ>{ 
ЮЖ>   class_with_possible_ressource  cwpr; 
ЮЖ>   dosomethingwith(cwpr); 
ЮЖ>} 

ЮЖ>//  Java 
ЮЖ>func() 
ЮЖ>{ 
ЮЖ>  class_with_possible_ressource  cwpr = new class_with_possible_ressource; 
ЮЖ>  if (cwpr->did_initialise_properly()) 
ЮЖ>  { 

ЮЖ>


Разве в С++ не требуется проверки, правильно инициализировался объект или нет?


dmitriid.comGitHubLinkedIn
Re[8]: Зачем нужен сборщик мусора? Как жить без деструкторов
От: Vamp Россия  
Дата: 05.08.08 15:11
Оценка: +1
M>Разве в С++ не требуется проверки, правильно инициализировался объект или нет?
Зависит от архитектуры класса. Можно просто исключение кинуть из конструктора. И тогда !ЧУДО! деструкторы всех уже сконструированных членов автоматически позовутся. Безо всяких catch-finally вообще!
Да здравствует мыло душистое и веревка пушистая.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.