Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, Head Ache, Вы писали:
HA>>К gc, не скрою, всегда относился с недоверием и вам не рекомендую считать его серебряной пулей. HA>>Например, подсчет ссылок: как определить, что объект не нужен. HA>>В общем случае, это эквивалентно задаче поиска циклов в ориентированном графе HA>>и корректное решение имеет сложность далеко не O(N). HA>>Тем не менее, полиномиального роста времени работы gc не наблюдается, HA>>так что можно смело утверждать, что где-то есть "затычка", которая работает "почти правильно".
K>Если бы вы утрудили себя почитать, как устроен и работает GC в управляемых средах вообще и в .NET в частности, то такие групости писать бы перестали...
Где-то есть доказательство корректности алгоритма?
Здесь я имею в виду, что в специальной литературе, вероятно, есть работы на эту тему.
То есть от мс было бы достаточно заявить, что именно реализовано и дать ссылки на первоисточники.
Имхо, это лучше, чем какие-то объяснения "на пальцах".
HA>Здесь я имею в виду, что в специальной литературе, вероятно, есть работы на эту тему. HA>То есть от мс было бы достаточно заявить, что именно реализовано и дать ссылки на первоисточники.
Алгоритм называется mark-and-sweep garbage collection и применяется большинством GC, которые существуют. Никто это не скрывал.
Остальное — тюнинх алгоритма для получения максимальной производительности.
HA>Имхо, это лучше, чем какие-то объяснения "на пальцах".
Вот в псевдокоде: http://lambda.uta.edu/cse5317/notes/node47.html
Идея очень простая, эффективная реализация — далеко не простая. Там уже нужно знать детали, которые проще всего "на пальцах".
Можешь тут почтитать http://blogs.msdn.com/b/abhinaba/archive/2009/01/25/back-to-basic-series-on-dynamic-memory-management.aspx
Здравствуйте, Head Ache, Вы писали:
HA>Здравствуйте, MxMsk, Вы писали:
MM>>Ну, хорошо. Ввели мы "нормальные" конструктор и деструктор. Что дальше? Каков usecase? Чем это лучше наличия конструктора и метода Dispose?
HA>Пример1. Была проблема, описанная в http://support.microsoft.com/default.aspx?scid=KB;EN-US;q326219 HA>Переводя на русский, при выходе из unmaged кода я должен гарантировать нужное состояние FPU. HA>То есть controlfp() должна быть ровно последней инструкцией, выполненной внутри длл. HA>Как видите, строгая гарантия обеспечена (и никакого отношения к управлению памятью эта проблема не имеет).
Так причем здесь "нормальные" конструктор и деструктор? Что в них "нормального"? Дело в вызове деструктора при выходе за пределы области видимости? Ну, а что делать, если ты этот объект куда-нибудь передашь?
HA>Пример2(классика). Критические секции, когда после Enter() следует гарантировать выполнение Leave() HA>Для C# это настолько сложная проблема, что даже понадобилось вводить новое ключевое слово lock (SyncLock в VB) ! HA>(так же как и using для IDisposable)
Какие-то у тебя проблемы надуманные. Это все такие мелочи: написать lock или try/finally.
HA>............ MM>>Если честно, то это ужасно. Ты превращаешь язык с GC в язык без GC. Лично мне хватает using. HA>По коду ужасов нет, все довольно коротко и тривиально. HA>К gc, не скрою, всегда относился с недоверием и вам не рекомендую считать его серебряной пулей.
Не считаю. Но раз уж работаем в среде с GC, то лучше уважать его и понимать, как жить в его мире, чем пытаться перестроить. Уж если много недоверия, не лучше ли взять unmanaged?
HA>DFS ( p ) =
HA>{ if *p record is unmarked
HA> then mark *p
HA> for each pointer p->fi of the record *p do DFS(p->fi) // это вроде рекурсия?
HA>}
Рекурсия, пока в объекте есть ссылки на другие объекты.
HA>which is called from every root:
HA>for each p in roots
HA> DFS(p) // это вроде O(N)?
конечно O(N)
HA>gc работал бы часами по такому алгоритму
С чего ты взял? А то что стандартные аллокаторы тоже O(N) причем на каждое выделение памяти, они же не часами работают.
Да и причем тут время работы, тебе нужна была корректность. Скорость, как я сказал, достигается конкретными оптимизациями.
например разделение на поколения, конкурентная сборка мусора итп.
Здравствуйте, vladimir.vladimirovich, Вы писали:
I>>Смайлик это значит я смеялся когда был в процессе написания сообщения.
VV>Правда? А ты когда смайлик пишешь, голову не наклоняешь?
Здравствуйте, hattab, Вы писали:
H>Хорошо хоть, что огромная часть мудачья убежала на шарпы с формулировкой "дельфи мертв"
Года полтора назад был на собеседовании в одной конторке... Ребята писали (в 2009-м!!!) на D7 (хорошо хоть, не на D5), изобретали библиотеку компонентов GUI Ну, типа, свой свечной заводик... (цитата) "с поддержкой юникода" (и при этом не могли толком объяснить, что же именно они там поддерживают: UTF8? UCS2? Whatever?) А еще в этом GUI была — я не шучу — утиная типизация, основанная на интерфейсах. То есть перед использованием нужно под try/except попытаться привести экземпляр TComponent к ожидаемому интерфейсному типу, и, если получилось — работать с ним, а нет — ну, типа, не судьба. Так что, как у классика
Пессимист(мрачно): Всё. Хуже уже не будет.
Оптимист(радостно): Да будет еще! Будет!!!
Люди! Люди, смотрите, я сошел с ума! Люди! Возлюбите друг друга! (вы чувствуете, какой бред?)
Здравствуйте, slava_phirsov, Вы писали:
s> H>Хорошо хоть, что огромная часть мудачья убежала на шарпы с формулировкой "дельфи мертв"
s> Года полтора назад был на собеседовании в одной конторке... Ребята писали (в 2009-м!!!) на D7 (хорошо хоть, не на D5), изобретали библиотеку компонентов GUI Ну, типа, свой свечной заводик... (цитата) "с поддержкой юникода" (и при этом не могли толком объяснить, что же именно они там поддерживают: UTF8? UCS2? Whatever?) А еще в этом GUI была — я не шучу — утиная типизация, основанная на интерфейсах. То есть перед использованием нужно под try/except попытаться привести экземпляр TComponent к ожидаемому интерфейсному типу, и, если получилось — работать с ним, а нет — ну, типа, не судьба. Так что, как у классика
s>
s> Пессимист(мрачно): Всё. Хуже уже не будет.
s> Оптимист(радостно): Да будет еще! Будет!!!
Здравствуйте, gandjustas, Вы писали:
HA>>gc работал бы часами по такому алгоритму G>С чего ты взял? А то что стандартные аллокаторы тоже O(N) причем на каждое выделение памяти, они же не часами работают.
Как же ты утомил!
Хоть раз ты изволишь объяснить что ж это за "стандартные" аллокаторы такие?
Да ещё и O(N).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, slava_phirsov, Вы писали:
_>(цитата) "с поддержкой юникода" (и при этом не могли толком объяснить, что же именно они там поддерживают: UTF8? UCS2? Whatever?)
Ну может они оччччень сильно напряглись и реализовали ваще весь Unicode стандарт, с блекждеком и всем что к нему полагается
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vladimir.vladimirovich, Вы писали:
I>>"... стоять раком" — привычно отозвалось эхо
VV>Какой интересный случай. А твой доктор об этом знает?
Да, случай интересный, ты представляешь меня секретаршей, рассказываешь про юзеров с одной сиской и одним яйцом, спрашиваешь у меня про пол...
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, Head Ache, Вы писали:
HA>>Здравствуйте, MxMsk, Вы писали:
MM>>>Ну, хорошо. Ввели мы "нормальные" конструктор и деструктор. Что дальше? Каков usecase? Чем это лучше наличия конструктора и метода Dispose?
HA>>Пример1. Была проблема, описанная в http://support.microsoft.com/default.aspx?scid=KB;EN-US;q326219 HA>>Переводя на русский, при выходе из unmaged кода я должен гарантировать нужное состояние FPU. HA>>То есть controlfp() должна быть ровно последней инструкцией, выполненной внутри длл. HA>>Как видите, строгая гарантия обеспечена (и никакого отношения к управлению памятью эта проблема не имеет). MM>Так причем здесь "нормальные" конструктор и деструктор? Что в них "нормального"? Дело в вызове деструктора при выходе за пределы области видимости? Ну, а что делать, если ты этот объект куда-нибудь передашь?
Зачем спрашиваешь, наверно и так ответ заранее знаешь
Если ссылка будет жить дольше объекта — будет плохо и никто такой код не пишет.
Если надо контролировать время жизни — использовать интеллектуальные указатели.
Обратите внимание, подход "не плати за то, чем не пользуешься": четко обозначить проблему и решать именно ее.
То есть если не нужны именно интеллектуальные указатели, они и не будут применяться.
Также есть варианты со статической памятью, глубоким копированием, специализированные аллокаторы.
Никто не мешает и сборщик мусора применять, только почему-то непопулярен этот подход.
Ни с gc, ни с каким-либо другим.
HA>>Пример2(классика). Критические секции, когда после Enter() следует гарантировать выполнение Leave() HA>>Для C# это настолько сложная проблема, что даже понадобилось вводить новое ключевое слово lock (SyncLock в VB) ! HA>>(так же как и using для IDisposable) MM>Какие-то у тебя проблемы надуманные. Это все такие мелочи: написать lock или try/finally.
Не мелочи, когда надо обеспечивать строгие гарантии самому.
try/finally в этом плане хуже, т.к. заставляет хоть как-то выставлять наружу внутреннюю реализацию.
Собственно, поэтому в cpp применение try/finally нежелательно.
HA>>............ MM>>>Если честно, то это ужасно. Ты превращаешь язык с GC в язык без GC. Лично мне хватает using. HA>>По коду ужасов нет, все довольно коротко и тривиально. HA>>К gc, не скрою, всегда относился с недоверием и вам не рекомендую считать его серебряной пулей. MM>Не считаю. Но раз уж работаем в среде с GC, то лучше уважать его и понимать, как жить в его мире, чем пытаться перестроить. Уж если много недоверия, не лучше ли взять unmanaged?
Предпочитаю. Но не всегда есть возможность выбирать.
