А так ли нужен сборщик мусора?

← →
Городской Шаман (2008-12-24 18:44) [0]

Одно из основных преимуществ, выдвигаемое фанатами управляемых языков, по типу Java и C# - сборщик мусора.

А так ли он важен и насколько он полезен для надежности и удобства проекта, ведь программист привыкнув что за него все сделает VM будет подсознательно ожидать что за освобождение системных ресурсов отличных от памяти позаботится среда. Поэтому будем иметь вместо утечек памяти - больше утечек системных ресурсов, которых часто меньше чем памяти.

Вместо сборщика мусора я считаю оптимальным использование Interface или smart_ptr<>, которое позволяет автоматически управлять временем жизни объекта, но делать это осознанно.

← →
Игорь Шевченко © (2008-12-24 18:52) [1]

Джоэла Спольски читать. Наизусть.

← →
Игорь Шевченко © (2008-12-24 18:53) [2]

И кстати Рэймонда впридачу

← →
Riply © (2008-12-24 18:56) [3]

> [0] Городской Шаман (24.12.08 18:44)
> А так ли он важен и насколько он полезен для надежности и удобства проекта,
> ведь программист привыкнув что за него все сделает VM будет
> подсознательно ожидать что за освобождение системных ресурсов отличных от памяти позаботится среда.

Видела код сильного С-шника писаный на Delphi (да и в Delphi он не первый раз замужем :) ).
В нескольких местах он забывал "убирать за собой".
Конечно, единичный пример не доказательсто истинности твоего утверждения, но о чем-то говорит :)

← →
Правильный$Вася (2008-12-24 19:02) [4]

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

короче, реализация мусорщика имеет важное значение

← →
lucy (2008-12-24 19:08) [5]

>ведь программист привыкнув что за него все сделает VM будет подсознательно ожидать

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

← →
Eraser © (2008-12-24 19:22) [6]

> [0] Городской Шаман (24.12.08 18:44)

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

нужен, НО с возможностью вызова деструктора вручную.

← →
Городской Шаман (2008-12-24 20:39) [7]

> Игорь Шевченко © (24.12.08 18:52) [1]
>
> Джоэла Спольски читать. Наизусть.

Он вроде бы тоже был против GC в качестве"серебряной пули". Или я читал не те его статьи?

← →
Городской Шаман (2008-12-24 20:45) [8]

> Игорь Шевченко © (24.12.08 18:52) [1]
>
> Джоэла Спольски читать. Наизусть.

Этот фрагмент?

Это отдельная песня: управление памятью. Вы знаете, как работает malloc? malloc поддерживает связный список свободных блоков памяти. Когда вы вызываете malloc, он проходит по списку в поисках блока достаточной длины. Найдя таковой, malloc разбивает его на две части (одна запрошенного размера, другая -- что осталось), кладёт остаток обратно в список свободных блоков, и возвращает указатель на блок запрошенного размера. Когда вы вызываете free, он просто добавляет освобождаемый блок в список свободных. Через какое-то время оказывается, что все свободные блоки маленькие, а нужен кусок побольше. Соответственно malloc объявляет перерыв и начинает перетряхивать список свободных блоков, сливая соседние маленькие блоки воедино, на что уходит три с половиной дня. В результате в среднем производительность malloc оказывается так себе (ему приходится постоянно ходить по цепочке свободных блоков), и иногда, внезапно, становится совсем никакой (когда приходится заниматься дефрагментацией). (Кстати, точно так же ведут себя и системы со сбором мусора, кто б мог подумать, так что заявления, которые часто можно услышать про неэффективность сборки мусора не совсем верны, ибо типичная реализация malloc обладает теми же самыми проблемами, хотя и в меньшей степени.)
http://russian.joelonsoftware.com/Articles/BacktoBasics.html

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

Проблема в другом - поведение программы (освобождение ресурсов) зависит от "научного прогноза астролога", если полагатся только на "умную" VM.

← →
Городской Шаман (2008-12-24 20:47) [9]

> Riply © (24.12.08 18:56) [3]
>
> > [0] Городской Шаман (24.12.08 18:44)
> > А так ли он важен и насколько он полезен для надежности
> и удобства проекта,
> > ведь программист привыкнув что за него все сделает VM
> будет
> > подсознательно ожидать что за освобождение системных ресурсов
> отличных от памяти позаботится среда.
>
> Видела код сильного С-шника писаный на Delphi (да и в Delphi
> он не первый раз замужем :) ).
> В нескольких местах он забывал "убирать за собой".
> Конечно, единичный пример не доказательсто истинности твоего
> утверждения, но о чем-то говорит :)

C++ не С. Объекты на стеке уничтожаются "магией компилятора", даже при исключении. С - это тот же assembler но с виртуальными регистрами (переменными).

← →
Городской Шаман (2008-12-24 20:50) [10]

> Eraser © (24.12.08 19:22) [6]
>
> > [0] Городской Шаман (24.12.08 18:44)
>
>
> > А так ли нужен сборщик мусора?
>
> нужен, НО с возможностью вызова деструктора вручную.

Тогда чем не устраивают interface или smart_ptr<>, кроме кольцевых ссылок (которые встречаются довольно редко и их можно разрулить) оно будет работать не хуже GC?

← →
Городской Шаман (2008-12-24 20:52) [11]

> lucy (24.12.08 19:08) [5]
>
> До первого отшибания сенсеем пальцев тетрадкой с нотами.
> Так что, считайте, что понятие "квалифицированный программист"
> включает в себя умение следить за ресурсами.

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

← →
lucy (2008-12-24 21:06) [12]

Городской Шаман (24.12.08 20:52) [11]

>так что "квалифицированных" в крупном проекте бывает не более 30%, остальное джониоры и сочувствующие.

Но вы ведь хотите стать квалифицированным программистом? Что еще вы можете сделать для отрасли, не являясь светилом Computer Science или крупным менеджером, почему-то вдруг решившим позаботиться о качестве?
Неужели у вас есть какие-то наполеоновские планы? Вы планируете встраивать умные указатели в Java и C#!?

← →
Игорь Шевченко © (2008-12-24 21:50) [13]

Городской Шаман (24.12.08 20:45) [8]

Нет, другой:

"Реальное и значительное повышение производительности мы получили от программирования на языках, автоматически управляющих памятью вместо вас. Это может быть подсчет ссылок или «сборка мусора», это может быть Java, Lisp, Visual Basic (даже 1.0), Smalltalk или любой язык написания скриптов. Если ваш язык программирования позволяет выделять кусок памяти без раздумий о его последующем освобождении, то вы используете язык с управляемой памятью, и вы будете значительно эффективней программиста, использующего язык, где управление памятью производится в явном виде"

http://russian.joelonsoftware.com/Articles/HowMicrosoftLosttheWaronA.html

← →
Городской Шаман (2008-12-24 22:52) [14]

> Игорь Шевченко © (24.12.08 21:50) [13]
> Если ваш язык программирования позволяет выделять кусок памяти без
> раздумий о его последующем освобождении, то вы используете
> язык с управляемой памятью, и вы будете значительно эффективней
> программиста, использующего язык, где управление памятью
> производится в явном виде"

Когда ресурсы системы для задачи почти бесконечны(фактически), то "математический" подход оправдан, так как компьютерное время стоит меньше времени программиста.

Но если поиск нужно элемента из БД делать в виде "select * from xxx;" а далее по локейте или (while not tb.eof) искать нужный нам элемент, то никаких ресурсов не хватит. А GC поощряет ресурсоизбыточное программирование.

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

← →
Игорь Шевченко © (2008-12-24 22:58) [15]

Городской Шаман (24.12.08 22:52) [14]

Пиши на ассемблере - твое полное право. Только не надо другим ничего доказывать.

← →
KilkennyCat © (2008-12-24 23:34) [16]

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

← →
Городской Шаман (2008-12-24 23:47) [17]

> KilkennyCat © (24.12.08 23:34) [16]
>
> я б вообще изменил всю логику. тянут мертвеца, а надо бы
> похоронить.

На какую?

← →
Городской Шаман (2008-12-24 23:47) [18]

> Игорь Шевченко © (24.12.08 22:58) [15]
>
> Городской Шаман (24.12.08 22:52) [14]
>
> Пиши на ассемблере - твое полное право. Только не надо другим
> ничего доказывать.

Если Lisp настолько хорош, то почему на нём не пишут?

← →
jack128_ (2008-12-25 00:06) [19]

> Если Lisp настолько хорош, то почему на нём не пишут?

потому что его его не поддерживает MS ?

← →
Игорь Шевченко © (2008-12-25 00:14) [20]

> Если Lisp настолько хорош, то почему на нём не пишут?

пишут

← →
XentaAbsenta © (2008-12-25 04:30) [21]

гм.. Я тоже вот задался таким вопросом после полутора лет проведённых на C#. В общем сделал вывод - кто-то там умный говорил, что в общем случае в программе не должно быть объектов, которые никому не принадлежат.
ИМХО: в программе архитектура первична, и если следовать мнемоническим правилам программирования, то GC не нужен и создан только для того, чтобы Sun и Microsoft могли заработать больше бабла.
---------------------
Почти в каждой программе используются системные ресурсы, в шарпе прямой вызов деструктора невозможен, остаётся писать IDisposable но весь фикус в том, что почти все классы со временем становятся IDisposable ибо окна, критические секции, мютексы (особенно именованые), файлы, подключения к БД, COM объекты (которые почему-то сами не релизятся... гм. странно), сокеты........
------
а вот строки массивы и списки - это тьфу!

← →
XentaAbsenta © (2008-12-25 04:31) [22]

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

← →
Городской Шаман (2008-12-25 05:40) [23]

> Игорь Шевченко © (25.12.08 00:14) [20]
> > Если Lisp настолько хорош, то почему на нём не пишут?
> пишут

Видно.
http://www.indeed.com/jobtrends?q=C%2B%2B%2C+Delphi%2C+Lisp&l=

← →
lucy (2008-12-25 07:56) [24]

Городской Шаман (24.12.08 23:47) [18]

>Если Lisp настолько хорош, то почему на нём не пишут?

http://www.paulgraham.com/popular.html

Из-за отсутствия критической массы библиотек продакшон уровня, в настоящий момент лисп является специализированным инструментом, примерно так же, как Delphi является средством для написания бухгалтерских приложений, и применяется там где нужна его динамика, символьные вычисления, DSL (для него существуют коммерческие IDE уровня Delphi: LispWorks, CormanLisp, доступны в условно-бесплатном варианте).

← →
Alkid (2008-12-25 11:40) [25]

> XentaAbsenta © (25.12.08 04:30) [21]
> ИМХО: в программе архитектура первична, и если следовать
> мнемоническим правилам программирования, то GC не нужен
> и создан только для того, чтобы Sun и Microsoft могли заработать
> больше бабла.

Ну это ты загнул. Сборщик мусора - штука полезная, но в рамках определённого круга задач. С другой стороны, есть языки, где сборщик мусора - это must have. Например - функционально-логические языки, использующие идиому IDS. Поскольку объект после создания и инициализации не может быть изменён, то он может быть переиспользован много раз в разных структурах, не принадлежа эксклюзивно никому. На смарт-поинтерах такую вещь решить сложно, ибо циклы.

← →
XentaAbsenta © (2008-12-25 12:42) [26]

что такое идиома IDS?

← →
Alkid (2008-12-25 13:51) [27]

> XentaAbsenta © (25.12.08 12:42) [26]
> что такое идиома IDS?

Immutable Data Structure. Т.е. когда у тебя объект во время создания/инициализации получает свои значения и не может быть изменён впоследствии. Распространено среди чистых декларативных языков.

← →
Alkid (2008-12-25 13:55) [28]

Вот тут ещё: http://en.wikipedia.org/wiki/Persistent_data_structure

← →
oxffff © (2008-12-25 14:20) [29]

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

Кому нужен. Кому не нужен.
Это еще одно средство для борьбы со сложностью.
Набор для борьбы каждый выбирает сам.

← →
@!!ex © (2008-12-25 14:23) [30]

ИМХО С++ обладает достаточным сборщиком.
Там нет проблемы со сбором мусора, пока не начинаешь работать напрямую с указателями.
При этом нет никаких проблем в том, чтобы указатели не использовать.
Подход: ты никогда не контролируешь сборку мусора - ИМХО не правильный.

← →
Ega23 © (2008-12-25 14:33) [31]

Скажем так. Сборщик мусора - вещь полезная. Но и собственная забота о памяти - вещь тоже полезная. Посему, ИМХО, было бы неплохо "совмещать".

← →
Alkid (2008-12-25 14:34) [32]

> @!!ex © (25.12.08 14:23) [30]

ИМХО, неправильный подход - это делать слишком обобщающие заявления.
В некоторых ситуациях необходим контроль над управлением память, в некоторых такой необходимости нет, а в некоторых этот контроль просто вреден.
Обобщать какое-то специфическое отношение к GC на весь спектр задач неразумно.

← →
KSergey © (2008-12-25 15:58) [33]

Я думаю, что все зависит от задач.
Либо нужно быстро, красиво, при этом легко модифицируемо и расширяемо - тут и язык со сборщиком мусора зашибись ка кподойдет.

Но есть моменты, где важно быстро и экономно ввиду объема и требованиям по времени - тама можно и пообсасывать без сборщика.

Но объемные и развесистые "склады" и т.п. писать на ассемблере - неразумно в плане затрат времени и оплаты высококвалифицированым разработчикам.

← →
int64 (2008-12-25 16:04) [34]

> XentaAbsenta © (25.12.08 04:30) [21]
> Почти в каждой программе используются системные ресурсы,
> в шарпе прямой вызов деструктора невозможен, остаётся писать
> IDisposable но весь фикус в том, что почти все классы со
> временем становятся IDisposable ибо окна, критические секции,
> мютексы (особенно именованые), файлы, подключения к БД,
> COM объекты (которые почему-то сами не релизятся... гм.
> странно), сокеты........!

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

← →
Григорьев Антон © (2008-12-25 16:05) [35]

Своевременное уничтожение объекта - это тоже средство обнаружения ошибок. Если я знаю, что с какого-то момента объект должен перестать существовать, и удаляю его, но по ошибке сохраняю на него ссылки, я (с большой вероятностью) получу ошибку, когда эти ссылки будут использованы. Это поможет мне обнаружить эти ссылки и исправить ошибку. А в системах со сборкой мусора просто явной ошибки не будет - забытые ссылки останутся, ненужный объект тоже останется, а программист, весьма вероятно, даже не заметит этой ошибки.

← →
int64 (2008-12-25 16:17) [36]

> Григорьев Антон © (25.12.08 16:05) [35]
> Если я знаю, что с какого-то момента объект должен
> перестать существовать

Та же проблема. Ты привязываешься к логике существования объекта. При сборках мусора такой логике не следуют.

← →
Юрий Зотов © (2008-12-25 17:42) [37]

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

Несколько утрируя, можно сказать, что если программист после New (GetMem, Create...) сразу же, на автопилоте пишет
try finally Dispose (FreeMem, Free...) end;
и только после этого начинает писать функциональный код в секции try...

... то такому программисту никакие сборщики мусора на фиг не нужны.

← →
Городской Шаман (2008-12-25 18:21) [38]

> int64 (25.12.08 16:04) [34]

Может сборщик мусора это и хорошо, но я всегда должен иметь возможность написать в коде kill имя_объекта и сборщик мусора должен уменьшить число ссылок объекта на 1, провести проверку необходимости удаления объекта и всех связанных и только потом продолжить выполнение со следующей команды.

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

← →
oxffff © (2008-12-25 18:39) [39]

> int64 (25.12.08 16:04) [34]
>
> > XentaAbsenta © (25.12.08 04:30) [21]
> > Почти в каждой программе используются системные ресурсы,
>
> > в шарпе прямой вызов деструктора невозможен, остаётся
> писать
> > IDisposable но весь фикус в том, что почти все классы
> со
> > временем становятся IDisposable ибо окна, критические
> секции,
> > мютексы (особенно именованые), файлы, подключения к БД,
>
> > COM объекты (которые почему-то сами не релизятся... гм.
>
> > странно), сокеты........!
>
> Вообще-то, первое от чего надо отказаться при переходе на
> программирование с GC, это от привязки логики приложения
> к времени жизни объекта.
> Поэтому, даже внедрив самопристреливающиеся интерфейсы,
> ты не заменишь GC, если у тебя в деструкторах будут "закрываться"
> ресурсы.

Точно нужно отказаться?
IDisposable это просто шаблон детерминированной финализации ресурсов.
А как быть если IDisposable уже вызван, а ссылка на объект висит.
Это из той же серии, что и так называемое воскрешение объекта.

Клиент что, должен писать?

If someObject.ValidState then

Где здесь +?

← →
Городской Шаман (2008-12-25 19:07) [40]

> Юрий Зотов © (25.12.08 17:42) [37]
>
> > А так ли нужен сборщик мусора?
>
> Несколько утрируя, можно сказать, что если программист после
> New (GetMem, Create...) сразу же, на автопилоте пишет
> try
>
> finally
> Dispose (FreeMem, Free...)
> end;
> и только после этого начинает писать функциональный код
> в секции try...
>
> ... то такому программисту никакие сборщики мусора на фиг
> не нужны.

Но согласитесь, то написать вместо try...finally, smart_prt<> удобнее, так как не нужно явно писать код освобождения ресурса.

← →
Юрий Зотов © (2008-12-25 19:45) [41]

> Городской Шаман (25.12.08 19:07) [40]

> написать вместо try...finally, smart_prt <> удобнее
Это всего лишь другая форма, суть не меняется.

> не нужно явно писать код освобождения ресурса.
1. Если этот ресурс - память, то написать короткое слово Free - не в лом.
2. А если это не память, то писать код освобождения все равно придется.

← →
Игорь Шевченко © (2008-12-25 19:48) [42]

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

← →
@!!ex © (2008-12-25 20:02) [43]

> [42] Игорь Шевченко © (25.12.08 19:48)

речь не о том, что не должно быть сборщика. речь о том, что до маразма доходить не должно.

← →
DVM © (2008-12-25 21:11) [44]

Сборщик мусора вещь конечно удобная, но предмет явно не первой необходимости. Меня лично как то всегда коробит тот факт, что где то, например, в C# я создаю объект, который потом когда то, причем не сразу, а может и никогда, если необходимости нет, будет освобожден GC.

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

← →
Игорь Шевченко © (2008-12-25 21:17) [45]

@!!ex © (25.12.08 20:02) [43]

> речь не о том, что не должно быть сборщика. речь о том,
> что до маразма доходить не должно.

Что есть маразм ?

← →
Городской Шаман (2008-12-25 21:54) [46]

> Игорь Шевченко © (25.12.08 19:48) [42]
>
> почему никого не удивляет, что у длинных строк, интерфейсов
> и динамических массивов есть "сборщик мусора" ? Может, ревнителям
> ручного управления памятью стоит озаботиться финализацией
> этих типов по мере их ненадобности ?

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

← →
Городской Шаман (2008-12-25 21:57) [47]

> Игорь Шевченко © (25.12.08 21:17) [45]
> Что есть маразм ?

Практическая остановка работы программы, когда этого захотелось сборщику, что в системах online-времени может вызвать проблемы. Если сервер "станет" на 10 секунд это может быть заметно, а такое на ASP.NET или C# вполне возможно.

← →
Игорь Шевченко © (2008-12-25 22:04) [48]

Городской Шаман (25.12.08 21:54) [46]

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

Не знаю, как в других языках, а в .Net эта проблема вроде как решена - Рихтер, по крайней мере довольно много писал на эту тему. Может, стоит почитать ?

Городской Шаман (25.12.08 21:57) [47]

> Практическая остановка работы программы, когда этого захотелось
> сборщику, что в системах online-времени может вызвать проблемы.
> Если сервер "станет" на 10 секунд это может быть заметно,
> а такое на ASP.NET или C# вполне возможно.

Такое возможно и без сборщика мусора, не стоит перекладывать поведение конкретных, не всегда грамотно написанных, программ на технологию в целом.

Может, опять же, стоит побольше почитать прежде чем устраивать флейм ?

← →
boa_kaa © (2008-12-25 22:04) [49]

> Городской Шаман (25.12.08 21:57) [47]

садись за Рихтера
прямо сейчас
чтобы едундой больше не болтать

← →
Псалтырь © (2008-12-25 22:56) [50]

> Игорь Шевченко © (25.12.08 19:48) [42]
>
> почему никого не удивляет, что у длинных строк, интерфейсов
> и динамических массивов есть "сборщик мусора" ?

Но и этим дядям иногда приходится звать на помощь Finalize. И задолбается искать тот, кто свято верит в непогрешимость самоубиения длинных строк.

← →
Городской Шаман (2008-12-25 23:29) [51]

> boa_kaa © (25.12.08 22:04) [49]
>
>
> > Городской Шаман (25.12.08 21:57) [47]
>
> садись за Рихтера
> прямо сейчас
> чтобы едундой больше не болтать

Я знаю про using, но в чем удобство по сравнению с тем же C++ + STL и basic_string ? То же самое но типа со сборщиком мусора, который собирает ошмётки полууничтоженных объектов(в которых вызвали Dispose, а удалить не удалили).

← →
boa_kaa © (2008-12-25 23:35) [52]

> Городской Шаман (25.12.08 23:29) [51]

давай так: ты не будешь гадать, благо С++ я тоже знаю
сначала прочитаешь, а потом будет о чем поговорить
а то беспредметно как-то получается, чесслово

ЗЫ. Извиняюсь, если грубовато получилось

← →
oxffff © (2008-12-26 00:12) [53]

>Игорь Шевченко © (25.12.08 22:04) [48]
>boa_kaa © (25.12.08 22:04) [49]

>
> > Городской Шаман (25.12.08 21:57) [47]
>
> садись за Рихтера
> прямо сейчас
> чтобы едундой больше не болтать

А сами то читали Рихтера?
Если нет, тогда читать книгу которая от 2007 CLR via C#.
стр. 504-507.

Так ли все там хорошо, как хотите представить?

← →
boa_kaa © (2008-12-26 00:16) [54]

> oxffff © (26.12.08 00:12) [53]

конкретный абзац, который докажет обратное

← →
oxffff © (2008-12-26 00:21) [55]

> boa_kaa © (26.12.08 00:16) [54]

Я же написал стр. 504-507 внимательно.
Прочитайте что делается с потоками при сборке и как.

← →
oxffff © (2008-12-26 00:22) [56]

> boa_kaa © (26.12.08 00:16) [54]
>
> > oxffff © (26.12.08 00:12) [53]
>
> конкретный абзац, который докажет обратное

Тогда и я позволю себе задать аналогичный вопрос.

Конкретный абзац, который докажет то что вы утвержаете?

← →
Игорь Шевченко © (2008-12-26 01:09) [57]

oxffff © (26.12.08 00:21) [55]

Я не настолько богат, чтобы покупать все книги Рихтера. Процитировать не затруднит ?

← →
Городской Шаман (2008-12-26 01:37) [58]

> Игорь Шевченко © (26.12.08 01:09) [57]
>
> oxffff © (26.12.08 00:21) [55]
>
> Я не настолько богат, чтобы покупать все книги Рихтера.
> Процитировать не затруднит ?

С этим вы согласились, что попытки обвинить компилятор в ошибках программиста ни к чему хорошему приведут? Но разработчики .NET похоже считали что их продукт будут использовать полные идиоты, которые не способны понять что же именно должен делать их код. И у них получилось, так как программы джониоров на C# или Java это тихий ужас, но который используется так как чуть-чуть работает.

Отсюда и проблема современного ПО (его глюков и кривизны), так как по мнению ведущих корпораций программист не должен быть умнее домохозяйки, а эволюционно все стремится к минимальному уровню, в данном случае - уровню IQ.

← →
boa_kaa © (2008-12-26 01:41) [59]

> oxffff © (26.12.08 00:21) [55]

читал
и что?
что там такого СТРАШНОГО и ХМУРОГО?

← →
boa_kaa © (2008-12-26 01:45) [60]

> Отсюда и проблема современного ПО (его глюков и кривизны),
> так как по мнению ведущих корпораций программист не должен
> быть умнее домохозяйки, а эволюционно все стремится к минимальному
> уровню, в данном случае - уровню IQ.

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

← →
Городской Шаман (2008-12-26 02:04) [61]

>
> вывод неверный
> современный программист должен быть быстр как молния, изрыгать
> пламя, как дракон и иметь Санчо Пансу, который будет за
> ним прибираться

Только этот "современный программист" напоминает фельдкурата Отто Каца у которого в помощниках бравый солдат Швейк(GC). С управляемыми языками все логично, если не обращать внимания на странности.

← →
boa_kaa © (2008-12-26 02:07) [62]

а странности - они везде есть

← →
Игорь Шевченко © (2008-12-26 02:07) [63]

Городской Шаман (26.12.08 01:37) [58]

"Вы, сударь, чепуху говорите и возмутительнее всего то, что говорите ее безапелляционно и уверенно."
(с)

← →
Eraser © (2008-12-26 02:11) [64]

> [58] Городской Шаман (26.12.08 01:37)

> Отсюда и проблема современного ПО (его глюков и кривизны)
> , так как по мнению ведущих корпораций программист не должен
> быть умнее домохозяйки, а эволюционно все стремится к минимальному
> уровню, в данном случае - уровню IQ.

пустые слова. примеры такого кривого современного ПО в студию.

между тем, на java"е написаны лучшие, на мой взгляд, IDE - eclipse, zend, netbeans - уж намного лучше и быстрее работают, чем IDE Delphi. offtop: кстати еще насчет языков со сборкой муссора - в новой CDS 2009 (вышла в этом месяце) есть поддержка .NET, совместимая с mono, вроде целая новая IDE - еще одна попытка внедрить кроссплатформенность.

← →
Городской Шаман (2008-12-26 02:12) [65]

> Игорь Шевченко © (26.12.08 02:07) [63]

Вот он уровень современного программиста

Вот в хелпе для каждой функции указана, thread-safe она или нет. А как свою собственную функцию сделать потокобезопасной ?
http://sql.ru/forum/actualthread.aspx?tid=626371

Здравствуйте!

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

Подскажите пожалуйста, как решаются такие проблемы, в каком направлении копать.
http://sql.ru/forum/actualthread.aspx?tid=626009

С первой формы запускается вторая.
Нужно присвоить значение из TextBox на первой форме Labelу на второй.

Пробовал разные варианты, но пока только вылетают ошибки.
http://sql.ru/forum/actualthread.aspx?tid=625958

Если бы вместо сборщика мусора написали заменитель мозгов...

← →
Игорь Шевченко © (2008-12-26 02:14) [66]

Городской Шаман (26.12.08 02:12) [65]

Вот он, уровень современного программиста:
http://www.delphimaster.ru/cgi-bin/forum.pl?n=18

Зато какой фон замечательный, а ?

Ничего, не ты первый, не ты последний.

← →
KilkennyCat © (2008-12-26 02:19) [67]

Может, я чего-то недопонимаю, да и ваще я себя неважно чувствую и только проснулся, но вся мусорная проблема возникает лишь из-за архитектуры и несовершенства компилятора. Что есть явление временное. Так что, нужен он или нет - рассуждать можно лишь применительно к конкретным условиям.

← →
Городской Шаман (2008-12-26 02:35) [68]

> Игорь Шевченко © (26.12.08 02:14) [66]

Мастерство программиста не в том, чтобы писать программы, работающие без
ошибок, а в том, чтобы писать программы, работающие при любом количестве
ошибок? (с) ankdot.ru

← →
Ans (2008-12-26 03:24) [69]

> Игорь Шевченко © (25.12.08 19:48) [42]
> почему никого не удивляет, что у длинных строк, интерфейсов
> и динамических массивов есть "сборщик мусора" ? Может, ревнителям
> ручного управления памятью стоит озаботиться финализацией
> этих типов по мере их ненадобности ?

Причем все указанные выше элементы могут быть уничножены ручками, так то:

для строки SetLength в 0
для динамического массива SetLength в 0 + можете указатель в nil
для интерфейсов - ну это позор не помнить про IUnknown.Release

← →
test (2008-12-26 07:04) [70]

Eraser © (26.12.08 02:11) [64]
Проведи эксперемент оставь запушенными в свернутом виде Дельфи и Eclipse, потом обоих разверни, получившийся эффект это как раз сборщик. Можно еще запустить Eclipse из под приложения логируещего состояние памяти, тоже посмотри что осталось в памяти и возрадуйся. Вообще на Java простой приклад который разок сработал и умер работает с каким угодно количеством не убитых обьектов в памяти. Проблемы начинаются если пишеш 24/7.

← →
Григорьев Антон © (2008-12-26 09:07) [71]

> Ans (26.12.08 03:24) [69]
> для интерфейсов - ну это позор не помнить про IUnknown.Release

Вот только вручную этот Release в Delphi вызывать не надо. Потому что при выходе интерфейсной переменной из области видимости или изменении её значения компилятор всё равно вызовет Release, а два Release"а одному интерфейсу ни к чему хорошему не приводят. Можно, конечно, извратиться и обнулить потом указатель низкоуровневыми средствами, но зачем? Проще сразу присвоить nil.

> Юрий Зотов © (25.12.08 17:42) [37]
> > А так ли нужен сборщик мусора?
>
> Несколько утрируя, можно сказать, что если программист после
> New (GetMem, Create...) сразу же, на автопилоте пишет
> try
>
> finally
> Dispose (FreeMem, Free...)
> end;
> и только после этого начинает писать функциональный код
> в секции try...
>
> ... то такому программисту никакие сборщики мусора на фиг
> не нужны.

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

← →
oxffff © (2008-12-26 09:34) [72]

> boa_kaa © (26.12.08 01:41) [59]
>
> > oxffff © (26.12.08 00:21) [55]
>
> читал
> и что?
> что там такого СТРАШНОГО и ХМУРОГО?

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

Однако сам код финализации может быть очень time consuming, и при обработке целого массива объектов. Тогда при использовании детерменированной финализации c IDispose, т. е. с размазыванием по времени превращает такого рода решение, исключительно в работу обычного менеджера памяти с отложенным освобождением памяти(чего можно добиться и в native Delphi с небольшой манипуляцией с Tobject.FreeInstance), однако с тем лишь исключением что при при дефрагментациии .NET корректирует
Managed pointers (type &) и Object references (type O), а у native этого нет.
Однако для больших объектов дефрагментация по возможности не используется. Так что в определенных ситуациях больше минусов, чем плюсов.
Я конечно уверен, что есть различные стратегии работы GC, однако они хорошо работают для одних задач и совершенно не работают для других.
Например я имею дело с real time приложением(распознаванием номеров) написанным на unmanaged С++ и C#. Разработчикам этого приложения пришлось переносить часть логики на С++ а для C# использовать детерминированное освобождение по причине того, что просто при сборке мусора приложение просто не обрабатывало входящий видеопоток. А минусы которого IDispose я уже упомянул выше в oxffff © [39].

← →
oxffff © (2008-12-26 09:39) [73]

> boa_kaa © (26.12.08 01:41) [59]
>
> > oxffff © (26.12.08 00:21) [55]
>
> читал
> и что?
> что там такого СТРАШНОГО и ХМУРОГО?

Теперь жду от вас разъяснение о полной свободе при GC.

← →
oxffff © (2008-12-26 09:47) [74]

> Игорь Шевченко © (26.12.08 01:09) [57]
> oxffff © (26.12.08 00:21) [55]
>
> Я не настолько богат, чтобы покупать все книги Рихтера.
> Процитировать не затруднит ?

Книги дома, я на работе. :)

← →
Eraser © (2008-12-26 10:01) [75]

> [70] test (26.12.08 07:04)

я сейчас как раз плотно работаю почти одновременно на Делфи и NetBeans - последний ощутимо шустрее работает. в Java"e несколько подходов к сборке муссора, в зависимости от разных условий применяются разные подходы.

← →
test (2008-12-26 10:08) [76]

Eraser © (26.12.08 10:01) [75]
Продукт имеет требование 24/7? Если нет всех прелестей Java не увидиш.
NetBeans имеет кучу нативных библиотек казалось бы а зачем они нужны?

← →
test (2008-12-26 10:11) [77]

Eraser © (26.12.08 10:01) [75]
Много вариантов сборки это случаем не два?
1. Проверяем все вплоть до температуры пользователя перед удалением
2. Не проверяем так много но тоже долго

← →
Eraser © (2008-12-26 11:12) [78]

> [76] test (26.12.08 10:08)

что значит 24/7? чтобы была 100% вероятность круглые сутки получать отклик от машины не дольше чем за 1 секунду?

> Много вариантов сборки это случаем не два?

как минимум два, возможно уже больше.

← →
test (2008-12-26 11:16) [79]

Eraser © (26.12.08 11:12) [78]
24/7 это работаем 24 часа в сутки и 7 дней в неделю, без Tomcat и прочих

← →
Eraser © (2008-12-26 17:17) [80]

> [79] test (26.12.08 11:16)

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

← →
test (2008-12-27 13:00) [81]

Eraser © (26.12.08 17:17) [80]
Обычно это достигается, нативной частью.

← →
tesseract © (2008-12-27 22:02) [82]

> как хорошая платформа для серверных приложений.

А разрабатывалась для стиральных машинок :-) Виртуальная машина имеет свои преимущества, особенно в среде 1- wire и иже в виду резкого снижения затрат именно на программировании контроллеров - огромное преимущество, там специалист по нативным приложениям редок и пуглив. А свин он и есть свин - пришлепка к идее именно сервлетов, как сердца всего. ИМХО mono для программирования именно кроссплатформенной части толстого клиента значительно оправданнее. Мне кажеться .Net и создавался MS именно для интервенции в *nix системы. Причем интервенция прошла не за счет самого Билли, а за счет Netware.

← →
Eraser © (2008-12-27 22:07) [83]

> ИМХО mono для программирования именно кроссплатформенной
> части толстого клиента значительно оправданнее

чем оправданнее?

← →
tesseract © (2008-12-27 22:12) [84]

> чем оправданнее?

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

← →
Johnmen © (2008-12-27 22:14) [85]

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

Без него мы все умрём в помоях....

← →
boa_kaa © (2008-12-27 22:16) [86]

> tesseract © (27.12.08 22:02) [82]
> ИМХО mono для программирования именно кроссплатформенной
> части толстого клиента значительно оправданнее.

блин, я сплю, что ли? 8-)

← →
Eraser © (2008-12-27 22:17) [87]

> [84] tesseract © (27.12.08 22:12)

хм. не наблюдаю особых тормозов со свином, но если уж проблема в этом - никто не запрещает использовать его прямого конкурента - SWT. в эклипсе используется именно SWT, а вот NetBeans написан на swing.

← →
Johnmen © (2008-12-27 22:17) [88]

> boa_kaa © (27.12.08 22:16) [86]
> блин, я сплю, что ли? 8-)

Ты уже умер...

← →
Городской Шаман (2008-12-27 22:53) [89]

> Johnmen © (27.12.08 22:14) [85]
>
>
> > А так ли нужен сборщик мусора?
>
> Без него мы все умрём в помоях....

Чисто не там где убирают...

← →
Johnmen © (2008-12-27 23:12) [90]

> Городской Шаман (27.12.08 22:53) [89]
> Чисто не там где убирают...

Знаю-знаю, проходили...

← →
test (2008-12-28 07:25) [91]

Eraser © (27.12.08 22:17) [87]
Исходники его посмотри и возрадуйся. Я как то видел переменную virginity в их исходниках, она за проверку задачи на второй запуск отвечала ))

Сборщик мусора не понацея, поскольку удалять ты ничего не можеш
/*
obj = null; // не удаление, а присваевание значения
*/
то писать надо еще более осторожно чем в языках с возможностью удаления.
Например String.replaceAll(text,text) вроде бы все впорядке только она на каждый вызов создает обьект в памяти который удалиться не скоро.
Причем класс String часть языка Java.

← →
Mystic © (2008-12-28 13:47) [92]

> В нескольких местах он забывал "убирать за собой".

В последних версиях Delphi первая строка в проекте это ReportMemoryLeakOnShutdown := True; В более ранних пишу свой небольшой модуль, который подключаю первым, и который просто проверяет была утечка или нет.

> Городской Шаман (24.12.08 20:45) [8]

Там скорее всего говорилось про реализацию HeapAlloc.

> Тогда чем не устраивают interface или smart_ptr<>, кроме
> кольцевых ссылок (которые встречаются довольно редко и их
> можно разрулить) оно будет работать не хуже GC?

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

> XentaAbsenta © (25.12.08 04:30) [21]

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

> ИМХО С++ обладает достаточным сборщиком.

Программисты C++ любят шутить на эту тему, что лучший язык, это язык который не порождает мусора :)

> я сейчас как раз плотно работаю почти одновременно на Делфи
> и NetBeans - последний ощутимо шустрее работает

Я с Java не сталкивался, но пятый Delphi у меня просто летает :)

← →
Mystic © (2008-12-28 14:09) [93]

А по сабжу мое мнение можно резюмировать следующим образом: можно разрабатывать программы как со сборкой мусора, так и без оной. На вкус и цвет, да и от задачи зависит. От коллектива в конце концов. При этом зачастую есть ресурсы, за которыми надо следить вручную в обеих моделях. Если человек начинает следить за некоторым типом ресурсов вручную, то из-за невнимательности то тут то там он начинает пропускать освобождение того или иного ресурса. И тут, как по мне, очень важно, чтобы был механизм учета таких утечек. Чтобы после выхода из программы отладчик ткнул меня носом: тут не освобожден IDisposable объект или утечка памяти.

← →
Городской Шаман (2008-12-28 18:03) [94]

Но если посмотреть на все время использования GC в .NET или Java то польза от сборщика мусора слегка перекрывает его вред. Программы со сборщиком намного стабильнее и удобнее не стали и глюки особо не уменьшились. Так что польза его сомнительна.

← →
Eraser © (2008-12-28 18:08) [95]

> [94] Городской Шаман (28.12.08 18:03)

> Программы со сборщиком намного стабильнее и удобнее не стали
> и глюки особо не уменьшились. Так что польза его сомнительна.

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

← →
Alkid (2008-12-28 19:28) [96]

> Городской Шаман (28.12.08 18:03) [94]
> Eraser © (28.12.08 18:08) [95]

Господа, а давайте в числах выражать подобные мысли? :)
В процентах, часах наработки на отказ и т.п. :)

← →
Городской Шаман (2008-12-28 20:13) [97]

> Eraser © (28.12.08 18:08) [95]

Угу позволяет просто решить те проблемы, которых в языках с детерминированной сборкой мусора (Delphi, C++) просто не существовало.

← →
boa_kaa © (2008-12-28 20:16) [98]

мужчины, а вам еще не надоело?
шли бы елку лучше б нарядили...

← →
Городской Шаман (2008-12-28 20:16) [99]

> Alkid (28.12.08 19:28) [96]
>
>
> > Городской Шаман (28.12.08 18:03) [94]
> > Eraser © (28.12.08 18:08) [95]
>
> Господа, а давайте в числах выражать подобные мысли? :)
> В процентах, часах наработки на отказ и т.п. :)

Если смотреть на отказоустойчивость программ на Delphi и .NET(не знаю на каком языке их писали), то фриварные продакшн-программы на Delphi в среднем более стабильны. Не знаю, глюки это VM, jit-компилятора, GC или программистов, но факт налицо.

← →
Alkid (2008-12-28 20:48) [100]

> Городской Шаман (28.12.08 20:16) [99]
> Если смотреть на отказоустойчивость программ на Delphi и
> .NET(не знаю на каком языке их писали), то фриварные продакшн-
> программы на Delphi в среднем более стабильны. Не знаю,
> глюки это VM, jit-компилятора, GC или программистов, но
> факт налицо.

"Огласите весь список, пожалуйста" (с).

← →
Игорь Шевченко © (2008-12-28 21:26) [101]

Городской Шаман (28.12.08 20:16) [99]

Ты проводил исследования ? Где можно ознакомится с результатами ?

← →
@!!ex © (2008-12-29 02:39) [102]

> Ты проводил исследования ? Где можно ознакомится с результатами
> ?

Вероятно магия подсказала.
Результаты можете узнать у ближайшей ведьмы.
Сеанс платный.

← →
test (2008-12-29 09:04) [103]

Игорь Шевченко © (28.12.08 21:26) [101]
@!!ex © (29.12.08 02:39) [102]

Мои проги

Исходные задачи
1. 24/7 перелопатить много текста в виде сервиса язык Java, только после вдумчевого управления удаления обьктов это начало работать, до этого постоянные проблемы с памятью приклад просто забивал всю память и висел.
2. 24/7 полученные данные сложить в БД во много потоков язык Дельфи, надо было просто написать, проблем с мусором вообще не было.

Такие факты подойдут?

← →
G.N. (2008-12-29 09:20) [104]

test (29.12.08 09:04) [103]

>1. 24/7 перелопатить много текста в виде сервиса язык Java, только после вдумчевого управления удаления обьктов
>только после вдумчевого управления удаления обьктов
>вдумчевого
>обьктов

Простите, вы уже празднуете?
Да, и не лишне было бы узнать, соотношение времени, которое вы уделяли программированию на Delphi/Java в течение всей вашей практики программирования?

← →
test (2008-12-29 10:23) [105]

G.N. (29.12.08 09:20) [104]
На Дельфи года 4 стажа, на Java года 3 стажа.

← →
Вариант (2008-12-29 10:30) [106]

> test (29.12.08 09:04) [103]

Исходные задачи
1) 24/7 перелопатить много чужого текста в виде сервиса на Дельфи, только после ...полгода убил одним словом и только тогда стало работать, до этого постоянные проблемы с памятью, приклад просто забивал всю память и висел, а так же отжирал хэндлы .
2) 24/7 полученные по TCP данные сложить в БД, приложение многопоточное на C#, проблем с мусором вообще не было.

← →
Игорь Шевченко © (2008-12-29 12:08) [107]

test (29.12.08 09:04) [103]

> Мои проги

Ну это несерьезно.

← →
test (2008-12-29 12:22) [108]

Игорь Шевченко © (29.12.08 12:08) [107]
А что серьезно?

← →
StriderMan (2008-12-29 13:14) [109]

Interface тоже препогано устроен. Я наступал на такие грабли, что в одном месте ссылка хранится как на обычный объект а в другом - на интерфейс этого же объекта. Так вот при освобождении ссылки на интерфейс объект оказывался прибитым. Это нормальное поведение или руки неоттуда растут? :)

← →
Alkid (2008-12-29 13:42) [110]

> StriderMan (29.12.08 13:14) [109]

Это руки не оттуда растут :)
Просто смешивать в рамках одной программы обращения и по интерфейсным ссылка и по "обычным" объектным ссылкам не рекомендуется в силу из сильно разной семантики управления временем жизни объекта. В качестве паллиатива можно отключить в объекте механизм подсчёта ссылок. Но всё равно останется сильный трабл - если у тебя объект был уничтожен ДО того, как все интерфейсные ссылки на него обнулены, то при попытке что-то присвоить такой "висящей" ссылке nil или ссылку на другой объект, ты словишь AV, ибо будет попытка вызова метода Release у дохлого объекта. В качестве паллиатива для паллиатива можно присваивать значение nil при помощи выражения
Pointer(InterfacePtr) := nil
Но это уже будет кривизна второго порядка.
Вообщем, лучше не смешивай.

← →
Alkid (2008-12-29 13:44) [111]

> test (29.12.08 12:22) [108]
> А что серьезно?

Провести обзор достаточно большого количества программ сравнимых характеристик (т.е. не сравнивать notepad с серверным приложением) и написанных с использованием разных технологий. Это достаточно сложное и дорогое исследование получится.

← →
Городской Шаман (2008-12-29 17:12) [112]

> Alkid (28.12.08 20:48) [100]
> > Городской Шаман (28.12.08 20:16) [99]
> > Если смотреть на отказоустойчивость программ на Delphi и
> > .NET(не знаю на каком языке их писали), то фриварные продакшн-
> > программы на Delphi в среднем более стабильны. Не знаю,
> > глюки это VM, jit-компилятора, GC или программистов, но
> > факт налицо.
>
> "Огласите весь список, пожалуйста" (с).

Хм. Посмотрел на все используемые мной утилиты. Утилиты на Java есть, используются регулярно, как клиент-банк, Jabber-сервер, сервер-поисковик по ftp. Чистых утилит на .NET у меня почему-то и нет. Конечно Office2007 и Autocad 2007 вроде бы используют .NET фреймворк, но в качестве плагина и написаны явно не на .NET. После поиска по инету в качестве достойной программы на .NET я нашёл только SharpDevelop, этакий простенький аналог NetBeans(Java) но только для программирования на .NET.

Вывод по части надёжности .NET программ был сделан после игры в freeware XNA игры. Скорее всего, он был неточен по причине того что .NET платформа для программистов уровня ПТУ, которые не способны вспомнить что у них делается на предыдущей строчке программы и которым нужен умный компилятор разбирающий такой вот код:
if (a==a) {a=a}

После этого можно даже сделать вывод как должна расшифровываться .NET (New Elementary Technology - .ПТУ), этакая начальная школа программирования для учеников пятых классов. Такое впечатление составили программы на .NET, которые были выложены на SourceForge.

Так что вывод вполне ясен - .ПТУ нужна для программистов начального уровня чтобы их программы хоть как-то работали, хотя бы на демонстрации заказчику. Отсюда и сборщик мусора, чтобы можно было "прогнать все переменные из программы", и VM, так как программист не способен понять, что такое ресурсы системы и зачем они нужны, и Jit компиляция - чтобы можно было свои баги свалить на компилятор.

Так что основной вывод - .NET со своим сборщиком мусора сделана для выпускников ПТУ, чтобы программирование не было сложнее укладки кирпичей на стройке. Но это не особо работает.

← →
StriderMan (2008-12-29 18:15) [113]

> Alkid (29.12.08 13:42) [110]
> Просто смешивать в рамках одной программы обращения и по
> интерфейсным ссылка и по "обычным" объектным ссылкам не
> рекомендуется в силу из сильно разной семантики управления
> временем жизни объекта. В качестве паллиатива можно отключить
> в объекте механизм подсчёта ссылок. Но всё равно останется
> сильный трабл - если у тебя объект был уничтожен ДО того,
> как все интерфейсные ссылки на него обнулены, то при попытке
> что-то присвоить такой "висящей" ссылке nil или ссылку на
> другой объект, ты словишь AV, ибо будет попытка вызова метода
> Release у дохлого объекта.

Я собственно так и выкрутился - в классе сделал пустышки для _AddRef и _Release. Полет нормальный.

← →
@!!ex © (2008-12-29 20:15) [114]

> [112] Городской Шаман (29.12.08 17:12)

Paint. Net - зачетная штука.

← →
Городской Шаман (2008-12-29 20:16) [115]

> @!!ex © (29.12.08 20:15) [114]
>
> > [112] Городской Шаман (29.12.08 17:12)
>
> Paint. Net - зачетная штука.

Если сравнивать с GIMP, то Paint.Net - отстой позорный.

← →
@!!ex © (2008-12-29 20:20) [116]

> [115] Городской Шаман (29.12.08 20:16)

Если сранвить с Photoshop, то GIMP отстой позорный? :))

А вообще я о качестве выполнения софта. к Паинт НЕту есть претензии по качеству?

← →
Городской Шаман (2008-12-29 20:30) [117]

> @!!ex © (29.12.08 20:20) [116]
>
> > [115] Городской Шаман (29.12.08 20:16)
>
> Если сранвить с Photoshop, то GIMP отстой позорный? :))
>
> А вообще я о качестве выполнения софта. к Паинт НЕту есть
> претензии по качеству?

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

Если SharpDevelop и Paint.Net - это флагманские программы на .NET, то скоро Python догонит это семейство языков программирования. А Perl уже на уровне.

← →
Alkid (2008-12-29 20:35) [118]

> Городской Шаман (29.12.08 17:12) [112]
> Так что основной вывод - .NET со своим сборщиком мусора
> сделана для выпускников ПТУ, чтобы программирование не было
> сложнее укладки кирпичей на стройке. Но это не особо работает.

Т.е. твой основной аргумент в споре - это то, что .NET - это технология для ПТУшников => на ней программы по определению будут глючнее, чем на Java.
В качестве аргумента ты привёл:
1. Аж 1 пример тупого кода.
2. Гениальную расшифровку названия ".NET"
Не то, что бы я был фанатом .NET`а, но твоя аргументация не выдерживает никакой критики :) Пример говнокода можно найти на любом языке и для любого языка можно придумать обидную расшифровку.

Вообще-то я изначально имел в виду какое-нибудь серьёзное исследование. Я понимаю, что ты сам вряди ли проводил подобное (я тоже не проводил), но может дал бы ссылку? Вот я, например, не имею подобных данных и огульных заявлений вида "программы использующие технологию X в целом в большей(меньшей) сепени обладают свойстом Y, чем программы, основанные на технологии Z" просто не делаю.

← →
Городской Шаман (2008-12-29 21:03) [119]

> Alkid (29.12.08 20:35) [118]

Хорошо. Возьмём на частном но аргументированном примере. Разработка игр на .NET. Даже имея такую мощную вещь как managed DirectX, разработка игр для сторонников .NET довольно сложна. Почему эта технология была исключена, ведь в DX нет готовых рисуемых окошек в десигн-тайм кнопочек и прочих. Нужно самому прорабатывать архитектуру игры.

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

Конечно данный движок позволит без особых усилий бывшему ПТУ-шнику написать очередной трехмерный тетрис, но грамотному разработчику игр, использующему такой движок как Ogre http://www.ogre3d.org/ , это не даст никаких преимуществ, даже свяжет его по рукам угловатостью и неэффективностью игрового движка XNA.

Что мы имеем - .NET привлекательная своей ПТУ-шной направленностью, так как позволяет быстро собрать какую-то поделку из кирпичиков среднего уровня не особо понимая как оно всё работает. А ничего толкового так создать нельзя.

PS
Кому не нравится XNA- игровой движок может заменить на XNA - игровой фреймворк, но смысл от этого не изменится.

← →
Alkid (2008-12-29 21:15) [120]

> Городской Шаман (29.12.08 21:03) [119]

Справедливо ли то, что ты сказал, относительно всех феймворков или же .NET тут чем-то особенно отличился? Я сильно не знаю XNA, но, насколько мне известно, предлагаемые ею шаблоны можно и не использовать, сторя приложение как себе вздумается.

И опять же, это не то, что я хочу увидеть. Как говорил герой одноц книги: "если бы за каждое логически безупречное утверждение, которое на пратктике оказалось полной чушью я получил по доллару, я бы давно стал миллиардером". Так же и тут - рассуждать можно сколько угодно, но это не заменит статистики, ибо практика - критерий истинности.

← →
Anatoly Podgoretsky © (2008-12-29 21:20) [121]

> Городской Шаман (29.12.2008 21:03:59) [119]

> Нужно самому прорабатывать архитектуру игры.

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

← →
Eraser © (2008-12-29 22:21) [122]

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

← →
DVM © (2008-12-29 22:22) [123]

> на .net не пишут шаровары

уже стали появляться

← →
oxffff © (2008-12-29 23:14) [124]

Давайте уже опускаться в глубины. Разберем так сказать по косточкам.

← →
Игорь Шевченко © (2008-12-29 23:26) [125]

> Так что основной вывод - .NET со своим сборщиком мусора
> сделана для выпускников ПТУ, чтобы программирование не было
> сложнее укладки кирпичей на стройке. Но это не особо работает.
>

Тебе самому не смешно ? Жил народ в заблуждении, Софт им открыл глаза, все срочно сваливают с .Net и пишут на ассемблере, так как нет языка более достойного для не-ПТУшников.

Впрочем, про твой случай еще Иван Андреевич Крылов писал, в басне, начинающейся со слов: "По улице слона водили".

← →
Agent13 © (2008-12-29 23:37) [126]

> > А вообще я о качестве выполнения софта. к Паинт НЕту есть
> > претензии по качеству?
>
> Есть - поделка уровня курсового в нормальном университете.
> Есть куча шаровар на нативных языках выше по качеству (в
> том числе специализированных).

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

> Что мы имеем - .NET привлекательная своей ПТУ-шной направленностью,
> так как позволяет быстро собрать какую-то поделку из кирпичиков
> среднего уровня не особо понимая как оно всё работает.

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

Кстати, по поводу упомянутого движка Ogre. Я специально нагуглил:
http://www.ogre3d.org/wiki/index.php/MOGRE - а это для кого тогда? Для извращенцев что ли?

← →
Городской Шаман (2008-12-29 23:38) [127]

> Игорь Шевченко © (29.12.08 23:26) [125]
>
> Впрочем, про твой случай еще Иван Андреевич Крылов писал,
> в басне, начинающейся со слов: "По улице слона водили".

Мне больше нравится басня "Квартет"

И ноты есть у нас, и инструменты есть;
Скажи лишь, как нам сесть!" -
...
А вы, друзья, как ни садитесь,
Все в музыканты не годитесь".

Хороший программист будет писать хорошие программы как сборщиком мусора, так и без (и не факт что сборщик будет давать ему больше преимуществ, чем проблем), а плохому нужно рассказать "как сесть". Вот для этого и был создан .ПТУ. Только пользы от "правильности посадки" не особо много.

← →
Городской Шаман (2008-12-29 23:45) [128]

> Agent13 © (29.12.08 23:37) [126]
> Кстати, по поводу упомянутого движка Ogre. Я специально
> нагуглил:
> http://www.ogre3d.org/wiki/index.php/MOGRE - а это для кого
> тогда? Для извращенцев что ли?

Для тех у кого нет части мозга, отвечающей за понимание указателей (с) Джоель Спольски

Тот же wxWidgets написан на С++, но его можно забиндить также и на python, и на Perl, и на C#. Но это не означает что C# лучше C++.

← →
oxffff © (2008-12-29 23:53) [129]

> Городской Шаман (29.12.08 23:38) [127]

Я честно какое время пристально обращал внимание .NET.
Читал, причем читал не простую литературу, которую тут приводили в качестве мастер-класс(дядю Рихтера тут любят по поводу и без повода).
А гораздо посерьезней.
И со временем к .NET как платформы для всего я охладел.
А то, что .NET это для так называемых .ПТУ я отчасти согласен.
Однако лично я стал чуствовать силу в связке между Native C++/Managed C++(С#).
Поэтому для некритичной и ленивой халявы - .NET, для критичной части С++|Delphi|ASM.

← →
oxffff © (2008-12-30 00:13) [130]

А вообще эта тема не раз пройдена и обмусолена.
Достаточно набрать в поисковике С++ vs C# или Delphi vs C#.
Там будут и доводы и доказательства.

← →
boa_kaa © (2008-12-30 00:31) [131]

> oxffff © (29.12.08 23:53) [129]

Да ради бога
Просто не надо кидаться тапочками и рассказывать всем про то, какие они адиёты, что им сборщик нравится
Мне он, например, ни разу не мешает, а только помогает
Пусть ему самому иногда нужно помочь тоже
Зато это помогает наводить генеральную уборку "когда хочешь" вместо педантичного поднимания фантиков
И не только
Просто пользоваться этим можно как мощным инструментом, а можно как дудкой-затычкой
И хорошо, что у разработчика есть выбор
У нативных его нет

Жаль, что кому-то что-то вечно нужно доказать

← →
test (2008-12-30 05:29) [132]

boa_kaa © (30.12.08 00:31) [131]
Проблема не в том что он есть, а в том что он иной раз такие фокусы показывает, мало не покажется.

← →
Вариант (2008-12-30 06:29) [133]

> test (30.12.08 05:29) [132]

Фокусы показывают все и вся, что сделано человеком. Примеров можно найти и для дельфи и для с++ и для чего угодно.

Кому не нравится сборщик мусора, тот ведь им и не пользуется?
Что касается меня, то у меня такая ассоциация - есть автомобиль с механической коробокй передач и есть с автоматической. Но коробка передач не отменяет необходимости знания и соблюдения правил дорожного движения. Для меня сборщик мусора- это коробка автомат. У механики есть свои преимущества, у автомата есть свои удобства. Ко всему надо привыкать и осваиваться.

← →
oxffff © (2008-12-30 07:43) [134]

> boa_kaa © (30.12.08 00:31) [131]
>
> > oxffff © (29.12.08 23:53) [129]
>
> Да ради бога
> Просто не надо кидаться тапочками и рассказывать всем про
> то, какие они адиёты, что им сборщик нравится

Я и не кидаюсь. Беру и читаю.
А вы как то трусливо пропустили мои посты [72],[73].
А я все жду.

← →
test (2008-12-30 10:36) [135]

Вариант (30.12.08 06:29) [133]
Зачем про сборщик мусора Java в документации заведомо ложные сведенья дают?
После выхода из видимости обьект сразу уничтожается, в реальности он удаляется когда на него ссылок 0.

← →
Alkid (2008-12-30 11:18) [136]

> test (30.12.08 10:36) [135]
> После выхода из видимости обьект сразу уничтожается, в реальности
> он удаляется когда на него ссылок 0.

Оба утверждения неверны!

← →
Вариант (2008-12-30 12:00) [137]

> test (30.12.08 10:36) [135]

> Зачем про сборщик мусора Java в документации заведомо ложные
> сведенья дают?
> После выхода из видимости обьект сразу уничтожается

Я не читал такого в JAVA, и в статьях по GC для JAVA. Я признаю, что читал в основном переводную литературу, а не оригинальную документацию...но возможно вы ошиблись? Но даже если нет, суть не в JAVA, тема поднята о сборщике мусора вообще, как "инструменте" А он существует и в .NET. и в оберонах и в функциональных языках. И технологии сборки мусора используются разные. Вопрос в том, а хороша ли сама идея? На это я писал про коробку автомат в [133].

← →
test (2008-12-30 13:12) [138]

Вариант (30.12.08 12:00) [137]
C Оберонами и .Net не работал говорю про то что на опыте пробывал.
Сама иде нормальна, не плохая, не хорошая, конкретные реализации вызывают уже другие чуства.

Alkid (30.12.08 11:18) [136]
В какой момент времени будет удален java.sql.Statement, после того как выполнил запрос и отдыл результат в java.sql.ResultSet? /*один из моментов который начинает очень интересно работать не под управлением сервера Tomcat и иже с ними*/

← →
Alkid (2008-12-30 13:17) [139]

> test (30.12.08 13:12) [138]

Ты имеешь в виду удаление самого объекта или закрытие запроса?
Я говорю об удалении объекта, это то, чем занимается сборщик мусора. Объект будет удалён при ближайшем запуске GC, если при этом он недостижим от корней. При этом на него могут ссылаться другие объекты. Если все они образуют часть графа объектов, недостижимую от корней, то все эти объекты будут уничтожены.

← →
test (2008-12-30 14:01) [140]

Alkid (30.12.08 13:17) [139]
Висеть в памяти этот обьект не удаляясь будет достаточно долго, проще пользоваться одним Statement на всю прогу, чем ждать когда память очистит сборщик.

> [127] Городской Шаман (29.12.08 23:38)

спор про "написание шаровар на плюсах vs написание шаровар на .нет" - это примерно спорить от том, что лучше: водка или коньяк.
Если хочешь быстро убраться в дрова - махни полбанки водки.
Если хочешь провести приятно время - сиди и цеди дорогой коньяк весь вечер

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

> [141] clickmaker © (30.12.08 14:16)

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

опыт показывает, что поделки как раз "копроративный софт", ну а в целом согласен.

> oxffff © (29.12.08 23:53) [129]
>
> Однако лично я стал чуствовать силу в связке между Native
> C++/Managed C++(С#).
> Поэтому для некритичной и ленивой халявы - .NET, для критичной
> части С++|Delphi|ASM.

Вот из-за таких как ты многие предприятия остаются на Windows.
Так как такие уродливые программы не могут работать ни в WINE@Ethersoft, ни в Mono 2.0.

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

Никто никому ничего не должен. Есть еще фактор, что многие shareware имеют свою долгую историю с времен, когда не было ни .NET, ни Java.

> iZEN © (30.12.08 15:54) [143]
>
> > oxffff © (29.12.08 23:53) [129]
> >
> > Однако лично я стал чуствовать силу в связке между Native
>
> > C++/Managed C++(С#).
> > Поэтому для некритичной и ленивой халявы - .NET, для критичной
>
> > части С++|Delphi|ASM.
>
> Вот из-за таких как ты многие предприятия остаются на Windows.
>
> Так как такие уродливые программы не могут работать ни в
> WINE@Ethersoft, ни в Mono 2.0.

:)
Далекоидущие выводы мне всегда интересны. Всегда готов на конструктивную критику. Только где аргументы?

>Вот из-за таких как ты многие предприятия остаются на Windows.
>Так как такие уродливые программы не могут работать ни в WINE@Ethersoft,

Ничего. Скоро дополируют РеактОС. Необходимость в альтернативах окончательно отпадёт. И это хорошо.

← →
test (2008-12-31 08:59) [147]

> Дмитрий Белькевич © (31.12.08 00:51) [146]
>
> >Вот из-за таких как ты многие предприятия остаются на Windows.
>
> >Так как такие уродливые программы не могут работать ни
> в WINE@Ethersoft,
>
> Ничего. Скоро дополируют РеактОС. Необходимость в альтернативах
> окончательно отпадёт. И это хорошо.

Ага. Придётся ставить в Wine микрософтовский .Net, и уже в нём запускать программы Windows, которые работают с .Net. Ж) Про Mono можно будет забыть как про страшный сон. Ж) Вот тогда воистину победит многоплатформенность Win32, а не .Net. Ж)

P.S.
Ребята из РеактОС тесно сотрудничают с проектом Wine.

> Вот из-за таких как ты многие предприятия остаются на Windows.

а что, собственно, плохого в Windows ?

> Дмитрий Белькевич © (31.12.08 00:51) [146]

> Ничего. Скоро дополируют РеактОС.

Я просто уверен, что ее НИКОГДА не дополируют. Как и Linux.

> oxffff © (30.12.08 07:43) [134]
> А вы как то трусливо пропустили мои посты [72],[73].

выражения выбираем
я тебе уже ответил

> boa_kaa © (01.01.09 21:34) [151]

Где ты конкретно ответил на [72], [73]?
Твои ответы являются просто общим трепом, не более и не менее.

Я тебе конкретно написал [72]. Где хотя твой ответ такого уровня, кроме общих фраз, что GC это решение всех проблем?

Теперь про выбор выражений. Про тапочки и идиотов написал ты.
Так что заруй глаза.
Жду твой развернутый ответ.

> заруй глаза.

разуй глаза. :)

← →
iZEN (2009-01-02 09:31) [154]

> oxffff © (01.01.09 23:48) [152]

покажи мне, где я писал, что GC - это решение всех проблем и я с тобой соглашусь. Детерминированно.

из всей твоей тиррады в 72 внимания заслуживает только последний факт кривого кода, когда разработчики действительно полагаются на сборщик, как на панацею. Потому что остальное лишь подводит к этому. И это единственная конкретика, остальное - вода.

что касается тормозов при освобождении "больших объектов". Большим может быть объект в двух случаях: либо он содержит большой объем данных (например, изображение), либо это объект с большим количеством объектов в себе (например, форма с двумястами батонами). При любых обстоятельствах освобождение памяти, используемой такими объектами - дело долгое. Дело выйдет из-под контроля только если программист - тапил и не понимает, что занятую память придется вернуть. И чем больше отгрызаемый кусок - тем быстрее. Если, конечно, он не используется. Но все эти случаи - скорее исключения, чем правила.

> boa_kaa © (02.01.09 11:02) [155]

При вызове сборщиком мусора финализатора, код финализатора может содержать time consuming операции. Для единичных объектов это может не являться проблемой. Однако для большого числа объектов это может приводить к проблемам. Поскольку достаточное количество объектов могут
входить в одно поколение и вызов их финализаторов может существенно занять время. Поскольку при сборке останавливаются все потоки
с управляемым кодом, приложение перестает откликаться и приминать внешние команды. А если приложение принимает видео-поток, то может просто потерять часть важных кадров, не дай бог это произвойдет в нужное время.
Все это наводит на простые мысли, что определенного круга задач программист должен использовать другую логику освобождения(неудобную для него логику), поскольку он уже обленился (.ПТУ) и просто полагается на сбор мусора.

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

// Allow your Dispose method to be called multiple times,
// but throw an exception if the object has been disposed.
// Whenever you do something with this class,
// check to see if it has been disposed.
public void DoSomething()
{
if(this.disposed)
{
throw new ObjectDisposedException();
}

> oxffff © (02.01.09 15:26) [156]

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

Не понимаю, что ты хочешь доказать? Что сборщик - это мировое зло? Давай это объясним разработчикам The Bat!, которые за собой столько мусора оставляют...

> Все это наводит на простые мысли, что определенного круга
> задач программист должен использовать другую логику освобождения

а я тебе уже устал об этом говорить

Для всего есть одно объяснение: не умеешь - не берись

> Давай это объясним разработчикам The Bat!, которые за собой
> столько мусора оставляют...

Как установлено?

← →
Alkid (2009-01-02 19:17) [160]

> oxffff © (02.01.09 15:26) [156]
> При вызове сборщиком мусора финализатора, код финализатора
> может содержать time consuming операции. Для единичных объектов
> это может не являться проблемой.

Не являюсь экспертом по тому, как в .NET работает GC, но, ЕМНИП, финализаторы там исполняются в отдельном потоке *после* цикла сборки мусора, который требует останова всех рабочих потоков.

> boa_kaa © (02.01.09 17:55) [158]
>
> > oxffff © (02.01.09 15:26) [156]
>
> А когда вызывается TForm.Free разве не останавливается выполнение?

Других потоков? Нет. Речь шла о них.

>
>
> А если контролов много и пошли по цепочке?
> А описанную проблему с остановкой мне приходилось реально
> видеть только на Mono. Причем богом затертой версии.
>
> Не понимаю, что ты хочешь доказать? Что сборщик - это мировое
> зло? Давай это объясним разработчикам The Bat!, которые
> за собой столько мусора оставляют...
>
>
> > Все это наводит на простые мысли, что определенного круга
>
> > задач программист должен использовать другую логику освобождения
>
> а я тебе уже устал об этом говорить
>
> Для всего есть одно объяснение: не умеешь - не берись

Ты снова продолжаешь считать себя экспертом.
Если продолжаешь себя им считать тогда тебе вопрос
В .NET есть понятие controlled mutability pointer.
Какие инструкции его генерируют, чем он отличается от простого managed pointer и самое главное для чего его ввели.
Ответишь, тогда я хотя бы буду считать что твои знания не меньше моих.
Но экспертом я себя не считаю.

> Alkid (02.01.09 19:17) [160]

Да так и есть. Однако сам этот поток имеет приоритет более высокий, чем рабочие потоки. Поэтому косвенно влияет на квант рабочим потокам.
Также этом поток может быть остановле входом состояние ожидания финализатором. Ну и тут Microsoft позаботился.
Но!!!
Однако сам процесс входа в состояние останова и дефрагментация может болезненно ударить по отклику приложения. Естественно речь идет не о GUI приложениях.

P.S. Но самое интересное, что освобождая некий ресурс в finalizator нужно хорошенько подумать и не выйдет ли это боком.

> oxffff © (02.01.09 23:08) [161]

> Ты снова продолжаешь считать себя экспертом.

где это было написано?
это ссылка на Рихтера произвела такой фурор?
за что же ты его так не любишь?

> Если продолжаешь себя им считать тогда тебе вопрос
> В .NET есть понятие controlled mutability pointer.
> Какие инструкции его генерируют, чем он отличается от простого
> managed pointer и самое главное для чего его ввели.

вот тебе встречный вопрос: какое отношение они имеют к теме?
просто ты про них знаешь и решил поумничать?
почитай вот тут: http://www.litera.ru/stixiya/authors/griboedov/
кстати, приколов с упаковкой вообще масса
и если любая сложность на тебя влияет так, что ты начинаешь орать "масдай", то сходи в баньке попарься, успокоительного глотни, в позе лотоса посиди

> Ответишь, тогда я хотя бы буду считать что твои знания не
> меньше моих.

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

> Но экспертом я себя не считаю.

и я тебя тоже не считаю
потому что если бы был, то не нападал бы в стиле детского сада "а вот докажи"

> boa_kaa © (03.01.09 00:35) [163]
>
> > oxffff © (02.01.09 23:08) [161]
>
> > Ты снова продолжаешь считать себя экспертом.
>
> где это было написано?
> это ссылка на Рихтера произвела такой фурор?
> за что же ты его так не любишь?
>

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

1. ECMA-335.
2. Expert .NET 2.0 IL Assembler (Serge Lidin)
3. Design and Implementation of Generics for the
.NET Common Language Runtime (Andrew Kennedy Don Syme)

Ты хоть про такие слышал?

> > Если продолжаешь себя им считать тогда тебе вопрос
> > В .NET есть понятие controlled mutability pointer.
> > Какие инструкции его генерируют, чем он отличается от
> простого
> > managed pointer и самое главное для чего его ввели.
>
> вот тебе встречный вопрос: какое отношение они имеют к теме?
> просто ты про них знаешь и решил поумничать?

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

> почитай вот тут: http://www.litera.ru/stixiya/authors/griboedov/
> кстати, приколов с упаковкой вообще масса
> и если любая сложность на тебя влияет так, что ты начинаешь
> орать "масдай", то сходи в баньке попарься, успокоительного
> глотни, в позе лотоса посиди
>
> > Ответишь, тогда я хотя бы буду считать что твои знания
> не
> > меньше моих.
>
> ты серьезно думаешь, что в противном случае я расстроюсь?
>

Расстраиваться не нужно. Нужно взять и прочитать.

1. ECMA-335.
2. Expert .NET 2.0 IL Assembler (Serge Lidin)
3. Design and Implementation of Generics for the
.NET Common Language Runtime (Andrew Kennedy Don Syme)

>
> > Но экспертом я себя не считаю.
>
> и я тебя тоже не считаю
> потому что если бы был, то не нападал бы в стиле детского
> сада "а вот докажи"

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

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

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

oxffff © (03.01.09 00:58) [164]

У меня вопрос - ты, собственно, что пытаешься доказать ?
Что "GC может создать проблемы для определенной части приложений" ?

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

Грубо говоря, код вида

var Foo: TBar; begin Foo := TBar.Create; ..... end;

лучше чем

var Foo: TBar; begin Foo := TBar.Create; try ..... finally Foo.Free; end; end;

Лучше значит - проще, понятней, сопровождабельнее.

А вся остальная заумь типа Expert .NET 2.0 IL Assembler - это для яйцеголовых, то есть, для ничтожной части программистов, которым по-настоящему нужно вникать во все эти дебри в узком кругу ограниченных задач.

> Игорь Шевченко © (03.01.09 01:10) [166]
> oxffff © (03.01.09 00:58) [164]
>
> У меня вопрос - ты, собственно, что пытаешься доказать ?
>

Я пытаюсь продемострировать, что работа GC может создать трудности для определенной части приложений.
Сам Рихтер например рекомендует отказаться от использования finalizators насколько это возможно.
И признает что правильный с точки зрения логики кода финализатора может оказаться не таким уж и правильным с точки зрения его работы.

> А вся остальная заумь типа Expert .NET 2.0 IL Assembler
> - это для яйцеголовых, то есть, для ничтожной части программистов,
> которым по-настоящему нужно вникать во все эти дебри в
> узком кругу ограниченных задач.

Проблема больше даже не в этом, а в том, что у .NET большая библиотека на все случаи жизни, которой пользуется программист .NET (.ТПУ).
И ее код вылизывается в Microsoft большой бандой людей. В том числе и информацией из bug list. Поэтому ошибки при программировании под .NET в этой части менее заметны.

> Поэтому ошибки при программировании под .NET в этой части
> менее заметны.

Однако шаблон IDiposable который предлагают в качестве способа детерминированой финализации, может создать не меньше проблем, если
не четко следовать инструкции по этому шаблону. Достаточно закоментировать выделенную строку и можно отгрести в первого взгляда "непонятные ошибки"

// Allow your Dispose method to be called multiple times,
// but throw an exception if the object has been disposed.
// Whenever you do something with this class,
// check to see if it has been disposed.
public void DoSomething()
{
if(this.disposed) {
throw new ObjectDisposedException();
}

А в том, что немаленькая часть программистов .ТПУ не всегда соблюдает правила, я более чем уверен.

> .ТПУ

.ПТУ.

> Достаточно закоментировать выделенную строку и можно отгрести
> в первого взгляда "непонятные ошибки"

Имеется ввиду не конкретно исключение ObjectDisposedException.

oxffff © (03.01.09 01:21) [167]

> Я пытаюсь продемострировать, что работа GC может создать
> трудности для определенной части приложений.

Для какой части приложений, если не затруднит ?

Написано довольно много кода на скриптовых языках, где управление памятью автоматическое, написано еще больше кода на Java, где используется сборщик мусора - как все эти приложения работают, если GC создает трудности и Рихтер рекомендует ?

Я понимаю, что тонкости вполне могут вылезать в определенные моменты в не менее определенных приложениях - однако, куда девать тот самый написанный работающий код ? :)

> Johnmen © (03.01.09 01:42) [172]
>
> > oxffff ©
>
> Эк тебя припёрло...:)
> А стОит ли?

Я закончил делать уже на вчера ремонт, подумал нужно срочно помыться, лечь пораньше спать и завтра(уже сегодня) встать пораньше, чтобы доштукатурить стену, вставить дверь, доделать проводку. Но залез на любимый форум. И понеслась. :)

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

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

Ещё один холивар, однако.
Давайте все вернёмся на С и на Pascal. Самые ярые противники "встроенных механизмов" могут вернуться на ASM.
Вот только "кривые руки" исправить нереально.

> Игорь Шевченко © (03.01.09 01:43) [173]
> oxffff © (03.01.09 01:21) [167]
>
>
> > Я пытаюсь продемострировать, что работа GC может создать
>
> > трудности для определенной части приложений.
>

Для критичных с точки зрения отклика приложений. Например я уже написал выше. Система распознавания изображений.

>
> Для какой части приложений, если не затруднит ?
>
> Написано довольно много кода на скриптовых языках, где управление
> памятью автоматическое, написано еще больше кода на Java,
> где используется сборщик мусора - как все эти приложения
> работают, если GC создает трудности и Рихтер рекомендует
> ?

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

>
> Я понимаю, что тонкости вполне могут вылезать в определенные
> моменты в не менее определенных приложениях - однако, куда
> девать тот самый написанный работающий код ? :)

Вот так и работают с неуловимыми ошибками.

> [179] Германн © (03.01.09 01:50)

бОльшая часть софта написана как раз криворукими программистами, зачастую программированием занимающимися по совместительству. это не т.н. коробочный софт (хотя есть и исключения), а специализированный софт, разработанный для какой-то конкретной предметной области для какого-то конкретного предприятия.
так что еще как реально исправить кривые руки, GC этому сильно способствует, за что ему и спасибо. по крайней мере утечек нет, в отличие от программ на Делфи. знали бы вы сколько народа пишет тот самый софт на обычном делфи, даже не подозревая, что нужно вызывать какие-то деструкторы.. и ничего, софт работает. ну вешает систему раз в день - эт мелочи. приходят на форум делфи-мастер и спрашивают как написать программу, которая перезапускает компьютер раз в день )
написать хоть как-то работающее реальное приложение на asm кривыми руками проблемотично.

> boa_kaa © (03.01.09 01:48) [176]
>
> > Я от тебя все жду, что ты хоть подкрепишь свои слова "сам
>
> > дурак" хотя бы техническими рассуждениями с конкретикой
>
> > работы, что позволит нам (всем) сделать вывод, что существуют
>
> > реализовать работу с GC так, чтобы использовать срезу
> с
> > GC как решение для промышеленного оборудования.
>
> ты либо не читаешь, что я пишу, либо не не понимаешь, либо
> игнорируешь
> во всех трех случаях идешь лесом, ибо достал

Последняя строка наиболее доказательная часть твоего утверждения.
Жаль что тратил на тебя время.

> кстати, дураком я тебя не считаю

Без комментариев.

> Eraser © (03.01.09 02:03) [182]
>
> > [179] Германн © (03.01.09 01:50)
>
> бОльшая часть софта написана как раз криворукими программистами,
> зачастую программированием занимающимися по совместительству.
> это не т.н. коробочный софт (хотя есть и исключения), а
> специализированный софт, разработанный для какой-то конкретной
> предметной области для какого-то конкретного предприятия.
>

Вот вот. И сколько я затратил времени и нервов, чтобы эти ЗЧ ака криворукие программисты, пользовались чем-то, что реально помогло бы исправить или хотя бы минимизировать их криворукость!
Ну например. Я настоял чтобы контора наша купила Эврику. Контора купила. Но вот заставить этих ЗЧ её использовать так и не удалось! Посему наша техподдержка до сих пор порою встаёт на уши получая от пользователей "доморощенные" сообщения об ошибках.

Игорь Шевченко © (03.01.09 01:10) [166]
Когда делфи дорастёт до объектов на стеке - тогда приведённый тобой код будет абсолютно бессмысленным, а сейчас я бы предпочёл истинно стековые объекты в C#.
И Джоел Спольски - не такой уж авторитет, многие о нём даже не слышали, и при этом немного потеряли. Кривые руки - это проблема криворуких, и GC тут ничем помочь не может.

oxffff © (03.01.09 01:36) [169]

> Однако шаблон IDiposable который предлагают в качестве способа
> детерминированой финализации, может создать не меньше проблем
>....

+1

oxffff © (03.01.09 01:53) [180]

> Для критичных с точки зрения отклика приложений.

Их надо обязательно писать на .Net ? Месье понимает толк в извращениях...

> Например я уже написал выше. Система распознавания изображений.

Сколько не видел систем распознавания изображений, нигде минимизация времени отклика не ставилась во главу угла.
Опять я что-то не то видел.

XentaAbsenta © (03.01.09 03:40) [185]

> И Джоел Спольски - не такой уж авторитет, многие о нём даже
> не слышали, и при этом немного потеряли

Кругозор нефигово бы расширить

> Игорь Шевченко © (03.01.09 13:38) [187]

Есть разные системы распознавания, например в моем случае(я не писал эту систему, я просто ее пользователь), где в определенные моменты в течение 1-15 мин необходимо принимать входящий видеопоток(его буферизация не поддерживается) сохранять его в памяти, дальше уже делать само разпознавание. Если в момент захвата raw видеопотока уйти на сбор мусора, то гарантированно можно получить потерю важных кадров.

> Игорь Шевченко © (03.01.09 13:38) [187]
> oxffff © (03.01.09 01:53) [180]
>
>
> > Для критичных с точки зрения отклика приложений.
>
>
> Их надо обязательно писать на .Net ? Месье понимает толк
> в извращениях...

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

oxffff © (03.01.09 16:44) [189]

> Вы ничего не перепутали?

Нет, я ничего не перепутал. Помимо сборки мусора у .Net есть еще факторы, не способствующие быстродействию, например, Just-In-Time компиляция.

> Я то как раз и остаиваю точку зрения, что не все можно написать
> на .NET.

Ради бога, отстаивай. Я просто не понимаю, причем здесь утверждение, что не все можно написать на .Net (точнее, не все имеет смысл писать на .Net - написать можно многое и на чем угодно, вопрос только - зачем) и оценка сборщика мусора, вынесенная в заголовок темы. По-моему, дискуссия ушла несколько не туда.

> И разработчикам пришлось делать нехитрые манипуляции, чтобы
> сбор мусора проходил не в момент захвата.

У разработчиков, по-видимому, дофига времени

> Игорь Шевченко © (03.01.09 17:07) [190]
> oxffff © (03.01.09 16:44) [189]
>
>
> > Вы ничего не перепутали?
>
>
> Нет, я ничего не перепутал. Помимо сборки мусора у .Net
> есть еще факторы, не способствующие быстродействию, например,
> Just-In-Time компиляция.

Есть средства для борьбы с этим NGEN.

← →
Анти.ПТУ (2009-01-03 21:50) [192]

Удалено модератором
Примечание: Рано вышел

> oxffff © (03.01.09 16:44) [189]

А я думаю что сборщик муссора и Just-In-Time компиляция это будущие. И такии программы будут не то что медленее работать, а быстрее или также. А вот разрабатывать будет проще. Просто пока эти вещи еще долеки от своего совершенства вот лет через 5-10.

> написать хоть как-то работающее реальное приложение на asm
> кривыми руками проблемотично.

Ты неповеришь, но на асаме его чуть ли не больше. Просто криворучек поменьше будет.

> Pavia © (04.01.09 05:17) [193]
>
> > oxffff © (03.01.09 16:44) [189]
>
> А я думаю что сборщик муссора и Just-In-Time компиляция
> это будущие. И такии программы будут не то что медленее
> работать, а быстрее или также. А вот разрабатывать будет
> проще. Просто пока эти вещи еще долеки от своего совершенства
> вот лет через 5-10.

Интересная логика.
Вы видили IL набор?
Хочется ли вам того или не хочется, но .NET должен лезть в неуправляемый код за той функциональностью которой нет в IL наборе. А такой функциональности подавляющая часть. Для этой цели(лезем в native) в IL есть инструкция

calli – indirect method call
Format Assembly Format Description
29 <T> calli callsitedescr Call method indicated on the stack with arguments described by callsitedescr.
......

The ftn argument is assumed to be a pointer to native code (of the target machine) that can be legitimately called with the arguments described by callsitedescr (a metadata token for a stand-alone signature). Such a pointer can be created using the ldftn or ldvirtftn instructions, or could have been passed in from native code.

Так вот, отсюда следует, что вызов этот идет через native инструкцию
call, если конечно у инструкции нет tail. prefix , который shall immediately precede a call, calli, or callvirt instruction. It indicates that the current method’s stack frame is no longer required and thus can be removed before the call instruction is executed. Because the value returned by the call will be the value returned by this method, the call can be converted into a cross-method jump.

А отсюда следует, прощай inline native кода. То есть как минимум потери на этом вызове. Так что хотите вы этого или нет.
Но .NET спасает только мощь процессора. И хороший prefetch кода по call переходу.

Хотя в delphi вызов API функции тоже идет через некоторый stub. :)

> А отсюда следует, прощай inline native кода. То есть как
> минимум потери на этом вызове. Так что хотите вы этого или
> нет.
> Но .NET спасает только мощь процессора. И хороший prefetch
> кода по call переходу.

Я всеже дополню свою мысль. Я думаю, что в Mircosoft тоже ребята непростые работают. Поэтому возможно придумали некий динамический inline native кода, но для этого код должен быть специальным образом написан и описан некоторой метаинформацией для JIT компилятора.
Хотя чего не сделаешь для продвижения .NET.

Eraser © (03.01.09 02:03) [182]

> написать хоть как-то работающее реальное приложение на asm
> кривыми руками проблемотично.

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

> oxffff © (04.01.09 11:01) [195]

NET он оптимальнее для работы с объектами. Поэтому тут именно и стоти ждать прирост. А то что родные(native) команды платформы нужно вызывать через call так это ничего. Это всеравно что жаловаться что процедуры через call вызываются. Он для этого и предназначен. Что касается инлине, то я думаю что в скором будущем введут intrinsics в NET. Тогда всем станет хорошо.

> NET он оптимальнее для работы с объектами.

Получается что другие языки менее оптимальные?

А так ли нужен сборщик мусора? Найти похожие ветки