Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>>Здравствуйте, Kluev, Вы писали:
K>>>Может их и можно проектировать, только зачем? Я еще не встречал ни одной системы имеющей сетевую (циклическую) архитектуру, которую вы тут проповедуете. Все что я видел, было древовидным (в крайнем случае), а обычно двух или трех уровневым. В такой архиетктуре проблеммы циклических ссылок просто нет. И такая архитектура вообщем всегда предпочтительнее сетевой. Чем проще тем лучше (проще не в смысле примитивнее).
SYG>>Архитектура — это одно, а ссылки между объектами — это другое. Архитектура — это то как модули друг друга импортируют.Модули всегда друг друга импортируют без циклов, стараются конечно — древовидно, но это не обязательно, главное что циклически модули не умеют импортироваться. А ссылки между объектами во время выполнения программы могут быть произвольные хоть циклические, хоть сами на себя — эти связи диктуются не архитектурой программы, а предметной областью для которой была написана программа. Если программа, например, написана для работы с графами, то понятно, что объекты этой программы ссылаются друг на друга так как в том графе нужно, к архитектуре же это отношения не имеет.
K>И где здесь проблемма в сылках между обьектами? Возьмите реальную жизнь — человеческое тело: почки, печень и т.п. на своих местах и в никаком сборщике мусора не нуждаются. Сборшик мусора прийдет в конце один для всех "обьектов" . А плагины — часы, майки и рубашки, контактируют только с малой частью системы и ниаких циклических ссылок нет. Ссылка на футболку из печени — это нонсенс. Сетевая архитектура как правило реализуется внутри модуля и особо не вылазит наружу. Взять к примеру геометрическое моделирование. Структуры данных настолько переплетены друг с другом что просто абсурдно разбивать — это на модули и компоненты. А наружу торчит весьма тонкий и простой интерфейс.
K>А гипотетическая ситуация когда все на все ссылается и без сборщикак мусора не как, помоему может родится только в академических умах или в воображении схоластов далеких от практической жизни.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, degor, Вы писали:
D>>А циклические/перекрестные ссылки все-таки зло. И в системах c GC с ними можно огрести проблем.
AVK>Каких?
Хит, конечно, — порядок удаления зависимых объектов. Плюс недетерминированность времени удаления, как следствие — подвисание объектов и ресурсов. Такие вещи как Dispose Method от хорошей жизни не появляются.
Здравствуйте, degor, Вы писали:
D>Согласен, но это никак не опровергает мое мнение, а дополняет его.
Ваш спор терминологический. Просто ты вкладваеш один смысл, а он другой.
D>Можно подумать, я не писал COM-объектов. С++ можно использовать на полную катушку, сделав всего две вещи — унаследоваться от IUnknown, и правильно его имплементировать.
А что такое сам IUnknown? Зачем он если язык поддерживает компонентность.
Вот чистый код на шарпе:
interface I1
{
int Method();
}
interface I2
{
int Method();
}
clas A : I1, I2
{
int I1.Method() { return 1; }
int I2.Method() { return 2; }
}
calss Test
{
static void Main()
{
I1 i1 = new A();
int i = i1.Method(); // i == 1
i = ((I2)i1).Method(); // i == 2
I2 i2 = (I2)i1;
i = i1.Method(); // i == 2
}
}
Заметь, ничего лишнего. Код чист и красив. Попробуй изобразить тоже самое на С++ и сравни результат. Объем кода, его чистоту. Они несравнимы даже если отбросить все библиотеки (куча кода по регистрации, разные мапы и т.п.). А уж если сравнить со всей подноготной, то все будет просто смешно.
Особенно некрасиво выглядит приведение через QI. Вся типобезопасность языка идет лесом.
D> А то, что плюсы — это бесконечное поле засеянное граблями известно всем.
Похоже не всем. Тут постоянно идут споры о крутизне плюсов. Собственно я не против того, что язык мощный. И что для некоторых задач ему до сих пор нет равных. Но возведение его в ранг божественных явный перебор.
VD>>1. Наличие не виртуального публичного интерфейса. D>Это проблема?
Да. Как минимум производительность страдает.
D>И как COM должен получать адреса функций без vtlb?
Это его проблемы. В дотнете эта проблема решена.
VD>>2. Множественное наследование. D>Во-первых, это общепризнанный источник неприятностей .
И тем не мнее это одна из ключевых фич языка. Без нее фиг бы ты получил все прелисти того же АТЛ. Ну, и многие боготворят ее.
D> Во-вторых, я не вижу применимости множественного наследования от _чужих_ компонентов. Для компонентов/объектов в одном проекте никто не мешает им пользоваться.
Есть язык мощный своими фичами. И есть их невилирование когда речь заходит о компонентности. Факт?
VD>>3. Приведение типов. VD>>4. Создание объектов. VD>>5. Импорт типов. D>Вот эти пункты я совсем не понял.
QI подменяет стандартные способы приведения типов. CI заменяет оператор new. Тлб и их импорт заменяет хэадеры. На лицо издевательство над славным языком. От языка камня на камне не осталось. Все положено на алтарь компонентности. Ну, и как результат отключение проверок типов языка (в QI и CI можно подсунуть любой указатель, один фиг к воиду приводить).
VD>>В общем, пол языка заменяется сурогатами. В том же дотнете компонентность встроена в языки и выглядт так как будтно это часть языка. D>Так за это и боролись.
Ну, вот о том и речь. Поддержки компонентности в С++ просто нет по сравнению с тем же Шарпом.
D>Я совершенно не собираюсь доказывать, что C++ — идеальный язык для компонентно-ориентированного программирования. Это не так. Но и в обиду его не дам.
Я в доволь натрахался делая КОМ-объекты на АТЛ. И перйдя на дотнет я имею намного больше с практически нулевыми усилями. Теперь чтобы заставить мнея сделать КОМ-объект на плюсах нужно очень постараться. Вот об это и речь. Думаю твоей аппонент как раз и пытался донести эту мысль. Ну, чутка пергнул палку.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, degor, Вы писали:
D>Хит, конечно, — порядок удаления зависимых объектов.
И что порядок? Объекты без финализатора могут удалятся в любом порядке, объекты с финализатором до вызова финализатора не удаляются. Где проблема, вызванная циклическими ссылками?
D> Плюс недетерминированность времени удаления,
При чем тут циклические ссылки?
D> как следствие — подвисание объектов и ресурсов.
Здравствуйте, bugmaker, Вы писали:
K>>И где здесь проблемма в сылках между обьектами? Возьмите реальную жизнь — человеческое тело: почки, печень и т.п. на своих местах и в никаком сборщике мусора не нуждаются. Сборшик мусора прийдет в конце один для всех "обьектов" . А плагины — часы, майки и рубашки, контактируют только с малой частью системы и ниаких циклических ссылок нет. Ссылка на футболку из печени — это нонсенс. Сетевая архитектура как правило реализуется внутри модуля и особо не вылазит наружу. Взять к примеру геометрическое моделирование. Структуры данных настолько переплетены друг с другом что просто абсурдно разбивать — это на модули и компоненты. А наружу торчит весьма тонкий и простой интерфейс.
K>>А гипотетическая ситуация когда все на все ссылается и без сборщикак мусора не как, помоему может родится только в академических умах или в воображении схоластов далеких от практической жизни.
B>нужен жизненный пример? B>пожалуйста, экосистема B>живые организмы — модули B>верхнее и нижнее звенья пищевой цепи — сборщики мусора
Ага, лев содержит ссылку на зайца, а заяц ссылку на почку волка. И все это чудно работает.
И где в этом примере циклические ссылки? и проблемма с ними?
Здравствуйте, AndrewVK, Вы писали:
VD>>Правда и в дотнете словить цикл можно. На событиях например. Забыл отписаться и приплыли тапочки к дивану.
AVK>И где там цикл?
Что в упор не видишь? Один объект держит другой. Тот подписывается на событие и первый схватывает второй. Ну, а так как один из них синглтон, то на лицо полный аналог проблемы циклической ссылки. Так что цигл то том всегда. Просто проблемы прявляются только при некоторых обстоятельствах.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, bugmaker, Вы писали:
K>>>И где здесь проблемма в сылках между обьектами? Возьмите реальную жизнь — человеческое тело: почки, печень и т.п. на своих местах и в никаком сборщике мусора не нуждаются. Сборшик мусора прийдет в конце один для всех "обьектов" . А плагины — часы, майки и рубашки, контактируют только с малой частью системы и ниаких циклических ссылок нет. Ссылка на футболку из печени — это нонсенс. Сетевая архитектура как правило реализуется внутри модуля и особо не вылазит наружу. Взять к примеру геометрическое моделирование. Структуры данных настолько переплетены друг с другом что просто абсурдно разбивать — это на модули и компоненты. А наружу торчит весьма тонкий и простой интерфейс.
K>>>А гипотетическая ситуация когда все на все ссылается и без сборщикак мусора не как, помоему может родится только в академических умах или в воображении схоластов далеких от практической жизни.
B>>нужен жизненный пример? B>>пожалуйста, экосистема B>>живые организмы — модули B>>верхнее и нижнее звенья пищевой цепи — сборщики мусора
K>Ага, лев содержит ссылку на зайца, а заяц ссылку на почку волка. И все это чудно работает.
K>И где в этом примере циклические ссылки? и проблемма с ними?
родственные особи содержат днк с частично совпадающей информацией, некоторые днк — бракованные, особи носящие их имеют низкую жизнеспособность
эти особи с низкой жизнеспособностью первыми подчищаются GC в виде хищников, вирусов и стихийных бедствий
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, bugmaker, Вы писали:
K>>>И где здесь проблемма в сылках между обьектами? Возьмите реальную жизнь — человеческое тело: почки, печень и т.п. на своих местах и в никаком сборщике мусора не нуждаются. Сборшик мусора прийдет в конце один для всех "обьектов" . А плагины — часы, майки и рубашки, контактируют только с малой частью системы и ниаких циклических ссылок нет. Ссылка на футболку из печени — это нонсенс. Сетевая архитектура как правило реализуется внутри модуля и особо не вылазит наружу. Взять к примеру геометрическое моделирование. Структуры данных настолько переплетены друг с другом что просто абсурдно разбивать — это на модули и компоненты. А наружу торчит весьма тонкий и простой интерфейс.
K>>>А гипотетическая ситуация когда все на все ссылается и без сборщикак мусора не как, помоему может родится только в академических умах или в воображении схоластов далеких от практической жизни.
B>>нужен жизненный пример? B>>пожалуйста, экосистема B>>живые организмы — модули B>>верхнее и нижнее звенья пищевой цепи — сборщики мусора
K>Ага, лев содержит ссылку на зайца, а заяц ссылку на почку волка. И все это чудно работает.
K>И где в этом примере циклические ссылки? и проблемма с ними?
дополнение
ссылка=днк передается другой особи при спаривании и что произойдет в дальнейшем с твоей личной наследственной информацией неизвестно, она тебе неподконтрольна
Циклов, скорей всего нет, но проблема есть. Если объект забыл отписаться от ивента, то он таки должен подвиснуть, пока источник событий не сдохнет. Или я не прав?
Здравствуйте, degor, Вы писали:
AVK>>Не было там никаких циклов, гонит он.
D>Циклов, скорей всего нет, но проблема есть.
Ты еще помнишь первоначальный вопрос?
D>А циклические/перекрестные ссылки все-таки зло. И в системах c GC с ними можно огрести проблем.
Каких?
Итак, я по прежнему хочу услышать какие проблемы можно огрести в системах с GC от циклических/перекрестных ссылок.
D> Если объект забыл отписаться от ивента, то он таки должен подвиснуть, пока источник событий не сдохнет. Или я не прав?
D>PS Мне действительно интресно это знать.
Именно так. А где здесь проблема? Если ты записываешь объект в контейнер то он не сдохнет пока не сдохнет контейнер. Делегат это тот же контейнер. В том примере проблема была из-за того что событие было у синглтона, а на него подписывались регулярно обновляемые сущности. И проблема там была не совсем с GC, а с неконтролируемым ростом числа подписчиков. С GC как раз проблему решить можно.
Здравствуйте, degor, Вы писали:
D>Циклов, скорей всего нет, но проблема есть. Если объект забыл отписаться от ивента, то он таки должен подвиснуть, пока источник событий не сдохнет. Или я не прав?
Прав. Но тут еще одна тонкость есть. Проблема появляется если тот самый источкник синглтон, т.е. никогда не умерает. Потому как в обычном случае умрут просто оба обхекта сразу.
D>PS Мне действительно интресно это знать.
Знай.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Правда и в дотнете словить цикл можно. На событиях например. Забыл отписаться и приплыли тапочки к дивану.
AVK>>И где там цикл?
VD>Что в упор не видишь? Один объект держит другой. Тот подписывается на событие и первый схватывает второй. VD> Ну, а так как один из них синглтон, то на лицо полный аналог проблемы циклической ссылки.
Там связь была только в одну сторону — от сингтона к форуму. Связи от форума к синглтону нет. Следовательно нет никакой циклической ссылки.
Если непонятно то вот примерная модель того что там происходит:
public class Test
{
public event EventHandler SomeEvent;
...
private ArrayList _items = new ArrayList();
public void Refresh()
{
_items.Clear();
foreach (Data d in SomeDataSource)
{
Item i = new Item();
SomeEvent += new EventHandler(i.Handler);
}
}
}
public class Item
{
public void Handler(object sender, EventArgs e)
{
...
}
}
D>>А циклические/перекрестные ссылки все-таки зло. И в системах c GC с ними можно огрести проблем.
AVK>Каких?
AVK>Итак, я по прежнему хочу услышать какие проблемы можно огрести в системах с GC от циклических/перекрестных ссылок.
Строго говоря, все проблемы с ссылками, в том числе перекрестными, возникают от неаккуратного проектирования/программирования.
Проблема перекрестных ссылок в том, что неопределен порядок удаления объектов. Если они захотят сделать что-то друг с другом перед смертью не факт, что это не окончится exception'ом. Но это больше теоретическая возможность, чем практическая.
D>> Если объект забыл отписаться от ивента, то он таки должен подвиснуть, пока источник событий не сдохнет. Или я не прав?
D>>PS Мне действительно интресно это знать.
AVK>Именно так. А где здесь проблема? Если ты записываешь объект в контейнер то он не сдохнет пока не сдохнет контейнер. Делегат это тот же контейнер. В том примере проблема была из-за того что событие было у синглтона, а на него подписывались регулярно обновляемые сущности. И проблема там была не совсем с GC, а с неконтролируемым ростом числа подписчиков. С GC как раз проблему решить можно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Там связь была только в одну сторону — от сингтона к форуму. Связи от форума к синглтону нет. Следовательно нет никакой циклической ссылки.
Привет. Сингл-тон постоянно доступен через статическое свойство, так что считай что связь есть постоянно. Да и не в этом дело. Дело и менно в том, что грабли похожие. Просто встречаются намного реже. Забавно, что именно приколы с синглтонами нас допекали три года назда на КОМ-е. Тоже вроде бы все хокей, но про бессмертность синглтона забываешь.
Тут тоже самое. Глядишь... в объекте никаких анменеджед-ресурсов. Что ему за зня диспоз городить? Ан нет тебе. С неявными ссылками нужно боросться. Я грешным делом думл, что события по умолчанию на виках сделаны.
Кстати, вики сами по себе средство борьбы с "проблемой которой нет".
AVK>Если непонятно то вот примерная модель того что там происходит:
Спасибо. Я эту багу сам делал.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, degor, Вы писали:
D>Проблема перекрестных ссылок в том, что неопределен порядок удаления объектов. Если они захотят сделать что-то друг с другом перед смертью не факт, что это не окончится exception'ом. Но это больше теоретическая возможность, чем практическая.
На практике с этим проблем нет. Да и с те ми же событиями один раз за два года вылезло. Сколько бы я такого на КОМ-е за тоже время словил бы?
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
D>>Проблема перекрестных ссылок в том, что неопределен порядок удаления объектов. Если они захотят сделать что-то друг с другом перед смертью не факт, что это не окончится exception'ом. Но это больше теоретическая возможность, чем практическая.
VD>На практике с этим проблем нет. Да и с те ми же событиями один раз за два года вылезло.
У опытных практиков, конечно.
VD>Сколько бы я такого на КОМ-е за тоже время словил бы?
Надо было больше практиковаться.
Здравствуйте, degor, Вы писали:
AVK>>Итак, я по прежнему хочу услышать какие проблемы можно огрести в системах с GC от циклических/перекрестных ссылок.
D>Строго говоря, все проблемы с ссылками, в том числе перекрестными, возникают от неаккуратного проектирования/программирования.
А при чем тут GC?
D>Проблема перекрестных ссылок в том, что неопределен порядок удаления объектов. Если они захотят сделать что-то друг с другом перед смертью не факт, что это не окончится exception'ом.
Нет такой проблемы. Все объекты с финализаторами не убираются сразу, а помещаются в finalization queue. После они отрабатывают (заметь, никто не убран) и лишь затем они уничтожаются, притом порядок уже абсолютно не важен.
. А плагины — часы, майки и рубашки, контактируют только с малой частью системы и ниаких циклических ссылок нет. Ссылка на футболку из печени — это нонсенс. Сетевая архитектура как правило реализуется внутри модуля и особо не вылазит наружу. Взять к примеру геометрическое моделирование. Структуры данных настолько переплетены друг с другом что просто абсурдно разбивать — это на модули и компоненты. А наружу торчит весьма тонкий и простой интерфейс.
.
