Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Ничего подобного. Это маньяк , который ходит по полю с топором среди живых, хватает каждого за руку и спрашивает окружающих, не знают ли они кто он такой. Если его никто не знает, он убивает несчастного, выносит тело за поле боя и идет дальше в поисках очередной жертвы.
Ну и как он может схватить за руку того, кого никто не знает? И спрашивает он только того, кого в данный момент держит за руку. И о тех, кого держит за руку в данный момент этот кто-то.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Тот же простейший копирующий ГЦ — это, к примеру, санитар, который заходит в палату и переводит всех живых пациентов в соседнюю, пустую. А когда приходит время делать то же самое уже в ней — первоначальная палата считается пустой.
Если бы не было финализации, можно было бы и так образно представить, а на самом деле, оставшиеся трупы надо с честью похоронить и только потом считать палату пустой.
Здравствуйте, vdimas, Вы писали:
AVK>>Ты всерьез считаешь, что проблема в отсутствии графических редакторов?
V>Справедливости ради, подобных редакторов хватает, но все они узкоспециализированные.
Вопрос только в причине и следствии.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
S>Нет, я допускаю, что есть определённый класс людей, которые называют себя "БД-программистами", но не умеют жить без визуального дизайнера. Нас они не интересуют в контексте данного топика — у них со здоровьем всё в порядке, мозг они не особенно нагружают. Потому что визуальном дизайнере не получится писать запросы в промышленных количествах. Тем более, когда речь идёт о сложных запросах с десятком таблиц.
Есть такой класс как 1С программисты в восьмерке с запросами на 10 листов и более с кучей подзапросов. Там очень сложно без дизайнера обойтись. Там отличие от нормального SQL это отсутствие в запросах локальных переменных, Exists, CTE, прямой записи. Джойны, пакеты присутствуют.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vdimas, Вы писали:
V>Если бы не было финализации, можно было бы и так образно представить, а на самом деле, оставшиеся трупы надо с честью похоронить и только потом считать палату пустой.
Только те, которые подписались при жизни на такую услугу — т.е. подавляющее меньшинство. Да и для финализированного объекта просто выполняется некая функция, а потом он становится частью пустого места между живыми на недетерминированное время — т.е. убийства или там разрушения как такового не происходит. т.е. сборщик мусора все равно никакой мусор не собирает — только периодически сбивает живых в одну кучу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
V>>Если бы не было финализации, можно было бы и так образно представить, а на самом деле, оставшиеся трупы надо с честью похоронить и только потом считать палату пустой.
K>Только те, которые подписались при жизни на такую услугу — т.е. подавляющее меньшинство.
Достаточно одного, чтобы сравнение фтопку.
K>Да и для финализированного объекта просто выполняется некая функция, а потом он становится частью пустого места между живыми на недетерминированное время — т.е. убийства или там разрушения как такового не происходит. т.е. сборщик мусора все равно никакой мусор не собирает — только периодически сбивает живых в одну кучу.
А чем, по твоему, в неуправляемом управлении памятью, выделенные участки не соответствуют? ИМХО, это настолько одно и то же (принципиально), что факт перемещения затем живых объектов вообще никакой рояли не играет. (Он играет рояль для будущих выделений) Тем паче, что объекты бывают запиненные, и как я уже говорил — достаточно всего одного, чтобы вся абстракция ни к черту.
Т.н. "разрушение" — это не более чем абстракция, это название той самой некоей ф-ии. Заметь, в С никакого разрушения нет, в отличие от С++. Т.е. мы имеем паттерн, поддержанный языком, а в дотнете целых два взаимодополняющих паттерна на абсолютно эту же тему, там с разрушением все даже круче чем в С++... А ты говоришь "разрушения не происходит"... Как не назови, только в печь не клади. (С)
Здравствуйте, vdimas, Вы писали:
K>>Только те, которые подписались при жизни на такую услугу — т.е. подавляющее меньшинство. V>Достаточно одного, чтобы сравнение фтопку.
Так это на сравнение не влияет. Объект сначала не мертвый, потому как на него есть ссылка в очереди на финализацию, и во время финализации его тоже никто не "убивает". После того, как на него исчезнет последняя ссылка он также неопределенное время будет находится в памяти, пока не будет перезаписан при уплотнении или занулен перед размещением нового объекта.
Тогда уплотнение понимать как "убийство"? Но ведь это "убийство массовое": ГЦ не имеет дел с отдельными объектами в данном случае — для него есть только интервал памяти, а какие там объекты и сколько их — не имеет значения. Индивидуально-то он работает только с живыми.
V>Как не назови, только в печь не клади. (С)
Проблема-то тут вот в чем: если думать, что ГЦ "убивает" объекты — из этого естественным образом следуют такие соображения:
Для "убийства" нужно проделаеть какие-то действия, много убийств — много действий, а значит если у нас в эфемерном сегменте было много объектов и все они подлежат сборке — ГЦ будет много и долго работать. А если "собирать" ничего не надо — то и затрат никаких. Естественно, что на самом деле в случае смерти всех объектов в эфемерном поколении ГЦ вообще ничего почти делать не будет, а в случае, когда все объекты остались живыми — он обойдет весь граф из этих объектов. Если остались живыми почти все — будет много копировать. Т.е. у программиста на основании неверной аналогии возникает неверное представление, которое приводит к тому, что он пессимизирует, думая что оптимизирует. Это не мои выдумки — я видел программистов, которые именно так и рассуждают. Да и на этом форуме мне сообщения таких программистов приходилось читать.
Т.е. идея о том, что ГЦ что-то "убивает" вредная — нужно помнить о том, что ГЦ в первую очередь работает с живыми объектами и объем работы зависит от кол-ва живых, а не от объема мусора. Точно также как и финалайзер в .net это не способ что-то там "убить" — он наоборот продлевает жизнь объекта.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Serginio1, Вы писали:
S> Есть такой класс как 1С программисты в восьмерке с запросами на 10 листов и более с кучей подзапросов. Там очень сложно без дизайнера обойтись. Там отличие от нормального SQL это отсутствие в запросах локальных переменных, Exists, CTE, прямой записи. Джойны, пакеты присутствуют.
Про 1с я ничего не знаю. Но знаю, что умелыми руками можно сделать настолько неудобный текстовый язык, что дизайнер покажется лучшим вариантом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Есть такой класс как 1С программисты в восьмерке с запросами на 10 листов и более с кучей подзапросов. Там очень сложно без дизайнера обойтись. Там отличие от нормального SQL это отсутствие в запросах локальных переменных, Exists, CTE, прямой записи. Джойны, пакеты присутствуют. S>Про 1с я ничего не знаю. Но знаю, что умелыми руками можно сделать настолько неудобный текстовый язык, что дизайнер покажется лучшим вариантом.
Там тотже SQL только даже несколько объектный. Мне лично больше нравится пользоваться дизайнером. Там ты можешь отдельно просматривать подзапросы с неограниченной вложенностью. Видеть связи. Очень удобно на больших запросах с большой вложенностью подзапросов.
Если бы еще и язык усовершенствовали к SQL 2008 мне было бы ооочень удобно.
Понятно, что с CTE и функциями возвращающими таблицу можно более читабельно разбить запрос, но и здесь дизайнер может тоже помочь не только для составления зпроса, но и для его чтения. Для интереса посмотри дизайнер в восьмерке. Опыт дело хорошее.
и солнце б утром не вставало, когда бы не было меня
S_>Как выразился действующий бригадный генерал армии США МакМастер (H. R. McMaster), пакет PowerPoint наносит вред не только с точки зрения затрат времени. Один из главных видов ущерба заключается в том, что презентации PowerPoint создают иллюзию понимания вопросов, о которых идет речь. Когда проблема описана в виде списков, схем и стрелок, вам кажется, что вы решили проблему, хотя на самом деле это не так.
Не ясно, при чем здесь поверпоинт, это всего лишь инструмент.
Генерал этот всего лишь перекладывает ответственность с подчиненных на поверпойнт.
, который ходит по полю с топором среди живых, хватает каждого за руку и спрашивает окружающих, не знают ли они кто он такой. Если его никто не знает, он убивает несчастного, выносит тело за поле боя и идет дальше в поисках очередной жертвы.
