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

VD>Привет. Сингл-тон постоянно доступен через статическое свойство, так что считай что связь есть постоянно.

С кем? Со всеми сразу? Впрочем неважно, точно такую же проблему, только в меньших масштабах можно получить и без синглтона.

VD> Да и не в этом дело. Дело и менно в том, что грабли похожие. Просто встречаются намного реже. Забавно, что именно приколы с синглтонами нас допекали три года назда на КОМ-е. Тоже вроде бы все хокей, но про бессмертность синглтона забываешь.

Может это и грабли, но к циклическим ссылкам они никакого отношения не имеют.

VD>Кстати, вики сами по себе средство борьбы с "проблемой которой нет".

Вики это средство организации кеширования в условиях GC.

AVK>>>Итак, я по прежнему хочу услышать какие проблемы можно огрести в системах с GC от циклических/перекрестных ссылок.
D>>Строго говоря, все проблемы с ссылками, в том числе перекрестными, возникают от неаккуратного проектирования/программирования.
AVK>А при чем тут GC?
При том, что он подбирает объекты в неопределенном порядке.

D>>Проблема перекрестных ссылок в том, что неопределен порядок удаления объектов. Если они захотят сделать что-то друг с другом перед смертью не факт, что это не окончится exception'ом.
AVK>Нет такой проблемы. Все объекты с финализаторами не убираются сразу, а помещаются в finalization queue. После они отрабатывают (заметь, никто не убран) и лишь затем они уничтожаются, притом порядок уже абсолютно не важен.
Проблема не в доступе к удаляемому объекту, который действительно никуда не денется, а к его ресурсам, которые он мог освободить.

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

D>>>Строго говоря, все проблемы с ссылками, в том числе перекрестными, возникают от неаккуратного проектирования/программирования.
AVK>>А при чем тут GC?
D>При том, что он подбирает объекты в неопределенном порядке.

Я уже два раза писал — проблем в связи с циклическими ссылками это не вызывает.

D>>>Проблема перекрестных ссылок в том, что неопределен порядок удаления объектов. Если они захотят сделать что-то друг с другом перед смертью не факт, что это не окончится exception'ом.
AVK>>Нет такой проблемы. Все объекты с финализаторами не убираются сразу, а помещаются в finalization queue. После они отрабатывают (заметь, никто не убран) и лишь затем они уничтожаются, притом порядок уже абсолютно не важен.
D>Проблема не в доступе к удаляемому объекту, который действительно никуда не денется, а к его ресурсам, которые он мог освободить.

Кто мог осовбодить и при чем тут GC? Если есть неуправляемые ресурсы то GC их никак не освобождает, их нужно освобождать вручную.

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

D>У опытных практиков, конечно.

И не только.

VD>>Сколько бы я такого на КОМ-е за тоже время словил бы?
D>Надо было больше практиковаться.

Куда же больше? Ты вон погляди сколько я статей по КОМ-у зафигачил...

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

AVK>С кем? Со всеми сразу?

Со свеми живыми объектами.

AVK>Впрочем неважно, точно такую же проблему, только в меньших масштабах можно получить и без синглтона.

Дык она самоустранится рано или поздно. А с синглтоном она устойчивая...

VD>>Кстати, вики сами по себе средство борьбы с "проблемой которой нет".

AVK>Вики это средство организации кеширования в условиях GC.

А ну, ну. Вот только их применяют еще и, чтобы от обратной связи уйти.

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

WH> Есть объект граф. Есть объект вершина графа. Граф владеет вершинами. Если убить граф то то он убьет вершины ибо он их владелец. Следовательно вершины могут как угодно ссылатся друг на друга от смерти в нужный момент это их не спасет. Врешина одного графа ссылающаяся на вершину другого графа есть ошибка ибо это не имеет смысла. Интерфейс графа не должен допускать такой возможности. Без объекта граф в общем случае обойтись нельзя ибо ни кто не отменял не связанные графы и тем болие ориентированные.

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

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

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

D>>У опытных практиков, конечно.

VD>И не только.

VD>>>Сколько бы я такого на КОМ-е за тоже время словил бы?
D>>Надо было больше практиковаться.

VD>Куда же больше? Ты вон погляди сколько я статей по КОМ-у зафигачил...

Прости, не смог удержаться.

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


K>>И где в этом примере циклические ссылки? и проблемма с ними?

B>родственные особи содержат днк с частично совпадающей информацией, некоторые днк — бракованные, особи носящие их имеют низкую жизнеспособность
B>эти особи с низкой жизнеспособностью первыми подчищаются GC в виде хищников, вирусов и стихийных бедствий

B>аналог ссылки — днк

Неверно. По ссылке можно удалить обьект, передать его куда нибудь (в функцию) или изменить (вызвать метод). А по днк что можно сделать? Эти аналогии сдесь не работают

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

SYG>А если этот Граф, нечаянно проболтается кому-нибудь внешнему о своих вершинах (сообщит кому-нибудь адрес объекта-вершины). Тогда ему, когда придет время умирать, уже нельзя будет удалить ни эту вершину, ни какую другую о которой та вершина была осведомлена. Ведь он понятия не имеет о том внешнем — работает оно с этой вершиной или больше не работает...

Логика неверна. Если разделяемым объктом (т.е. имеет несколько владельцев) является граф, то висящая ссылка на вершину — это неверный дизайн. Когда нужно будет удалить граф то он останется в памяти из-за этой ссылки. Т.е. ресурс не будет освобожден и в этом случае от GC вреда больше чем пользы. Более того возможно непредсказуемое поведение из-за того что граф как-бы удален, а вершина осталась.

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

Т.е. проблема не в ссылках или GC, а в дизайне(головах).

И более того в сложных случаях когда все друг на друге завязано гораздо лучше ручное управление памятью, например геометрическая модель: обьект один — тело, но состоит из целой кучи edges,faces,nodes,bounds,curves,surfaces,vertices,triangles и куча всяких прокешированных данных и все циклично ссылается друг на друга. Если я накрыл тело то висящая сылка в программе к примеру на face — откровенно неверный дизайн. Более того когда память освобождается ручками, то при обращении к этой ссылке будет лекго обнаружимая ошибка, а если все это барахло (из-за) подвисшей ссылки удерживается GC в памяти, то это самое настоящее проклятье. Все может тихой сапой отработать, однако ошибку попробуй найди.

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

В любом случае тонкая, ручная и профессиональная работа на С++ всегда будет в цене.

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

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


K>>>И где в этом примере циклические ссылки? и проблемма с ними?

B>>родственные особи содержат днк с частично совпадающей информацией, некоторые днк — бракованные, особи носящие их имеют низкую жизнеспособность
B>>эти особи с низкой жизнеспособностью первыми подчищаются GC в виде хищников, вирусов и стихийных бедствий

B>>аналог ссылки — днк

K>Неверно. По ссылке можно удалить обьект, передать его куда нибудь (в функцию) или изменить (вызвать метод). А по днк что можно сделать? Эти аналогии сдесь не работают

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

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

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

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

B>мыслите более абстрактно
B>аналогом модуля является не отдельная живая особь, а генетическая линия

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

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

И причем здесь программирование, модули и сборка мусора? В природе вобщем-то нет никакой сборки мусора, т.к. мусора просто нет. Что считать мусором в природе? Если вы считаете труп мусором, то для бактерий, червей и т.п это лакомство. И почему бы тогда не считать мусором ваш собственный обед? А его употребление сборкой мусора и освобождение природы от бремени вареной картошки и т.п?

З.Ы. ИМХО просто неуместно проводить аналогии в программирование с природой.

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

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

B>>мыслите более абстрактно
B>>аналогом модуля является не отдельная живая особь, а генетическая линия

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

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

K>И причем здесь программирование, модули и сборка мусора? В природе вобщем-то нет никакой сборки мусора, т.к. мусора просто нет. Что считать мусором в природе? Если вы считаете труп мусором, то для бактерий, червей и т.п это лакомство. И почему бы тогда не считать мусором ваш собственный обед? А его употребление сборкой мусора и освобождение природы от бремени вареной картошки и т.п?

K>З.Ы. ИМХО просто неуместно проводить аналогии в программирование с природой.

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

Здравствуйте, S.Yu.Gubanov, Вы писали:


SYG>А если этот Граф, нечаянно проболтается кому-нибудь внешнему о своих вершинах (сообщит кому-нибудь адрес объекта-вершины). Тогда ему, когда придет время умирать, уже нельзя будет удалить ни эту вершину, ни какую другую о которой та вершина была осведомлена. Ведь он понятия не имеет о том внешнем — работает оно с этой вершиной или больше не работает...

То что он нечаянно проболтается — это censored дизигна. Все должно быть параллельно и перпендикулярно — объекты, использующие граф должны умирать раньше него. Или по карйней мере должен быть формализован порядок — кто что удаляет. Это не вопрос языка — это вопрос проектирования системы

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

K>>И причем здесь программирование, модули и сборка мусора? В природе вобщем-то нет никакой сборки мусора, т.к. мусора просто нет. Что считать мусором в природе? Если вы считаете труп мусором, то для бактерий, червей и т.п это лакомство. И почему бы тогда не считать мусором ваш собственный обед? А его употребление сборкой мусора и освобождение природы от бремени вареной картошки и т.п?

K>>З.Ы. ИМХО просто неуместно проводить аналогии в программирование с природой.

B>а какое отношение имеет программирование к посроению архитектуры различных систем, модульности, сборке мусора=более точно — неиспользуемого материала?
B>я не знаю как точно назвать данную дисциплину (пусть будет системная архитектура) , но она к программированию имеет такое же отношение как и ко всем другим профессиональным сферам человеческой деятельности и вообще к функционированию чего либо не представляющего собою единое целое (как например электрон, фотон и тп)

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

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

K>Логика неверна...

Какая логика? Давайте придумает другую логику. Освободим свой разум от стереотипов наложенных отсутствием сборщика мусора.


Вот сейчас пришел в голову такой вариант:


Сначала вариант реализации со счетчиком ссылок

Есть объект, который состоит из 1) модели (предметной области); 2) визуализатора модели 3) редактора модели

Model = INTERFACE
    //.. что-то из предметной области
  END;

View = INTERFACE
    FUNCTION  Model: Model; // Представление осведомлено о модели чтобы уметь ее рисовать
    PROCEDURE DrawTo(G: Graphics);
    //...
  END;

Edit = INTERFACE
    FUNCTION  Model: Model; // Редактор осведомлен о модели чтобы уметь ее редактировать
    FUNCTION  View : View;  // Редактор осведомлен о представлении чтобы уметь рисовать модель
    PROCEDURE Show;         // Создает и показывает форму редактирования объекта
    //...
  END;

Controller = INTERFACE
    FUNCTION  Model: Model; // Контроллер владеет моделью объекта
    FUNCTION  View : View;  // Контроллер владеет представлением объекта
    FUNCTION  Edit : Edit;  // Контроллер владеет редактором объекта
    //...
  END;

Controller — это, собственно сам объект, а Model, View, Edit — это "запчасти" объекта. То есть фактически получается, что один объект из предметной области представлен четырьмя объектами (экземплярами разных классов) из языка программирования.


А теперь тоже самое, но при наличии в системе сборщика мусора:

Теперь никто друг другом не владеет

  Controller = INTERFACE
    FUNCTION  Model: Model;
    FUNCTION  View : View;
    FUNCTION  Edit : Edit;
  END;

  Model = INTERFACE (Controller)
    //.. что-то из предметной области
  END;

  View = INTERFACE  (Controller)
    PROCEDURE DrawTo();
    //...
  END;

  Edit = INTERFACE (Controller)
    PROCEDURE Show;
    //...
  END;

Теперь отдельного класса реализующего интерфейс Controller больше нет. Просто классы реализующие интерфейсы Модели, Визуализатора и Редактора также реализуют и интерфейс Controller-а. То есть классов стало 3 вместо 4-х. Экономия, однако.

        Model----View
          |        |
          |        |
          +--Edit--+

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

  Controller = INTERFACE
    FUNCTION  Model: Model;
    FUNCTION  View : View;
    FUNCTION  Edit : Edit;
  END;

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

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

K>>Логика неверна...

SYG>Какая логика? Давайте придумает другую логику. Освободим свой разум от стереотипов наложенных отсутствием сборщика мусора.

SYG>Вот сейчас пришел в голову такой вариант:

SYG>Сначала вариант реализации со счетчиком ссылок
/*поскипано*/

Гы. и зачем так усложнять себе жизнь?
Вот вариант, бес ссылок и сборщиков:

class View {};
class Edit : View {}; // edit - это тоже view

class Controller { // владелец модели и вью-х
    Model            mdl;
    list<View*>    observers; // views-n-edits 
};

// глобальный обьект SDI-приложения
class SDIApp {
    Controller        ct;
    SDIFrame            mainFrame;
} theApp;

// глобальный обьект MDI-приложения
class MDIApp {
    list<Controller*>        cts;
    MDIFrame                    mainFrame;
} theApp;

Все ноги растут из глобального обьекта theApp котроый определяет SDI or MDI интерфейс.
В SDIApp контроллер-часть агрегата (используется повторно via clear()), умирает вместе с theApp.
модель часть контроллера — используется повторно через cleаr(), views умирают вместе с контроллером или при открытии-закрытии. Либо используются повторно в тривиальном случае.

Все просто прозрачно и очевидно. Зачем городить огород? Когда и так ясно кто кем владеет. Когда у нас SDIApp можно еще более "упростить" обьединив контроллер с App, но я против такой экономии т.к. потом трудно будет в MDI переделывать.

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

class Controller { 
    Model    mdl;
    MyView mainView;
      MyEdit mainEdit;
      list<View*>   pluggedViews;
};

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

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

VD>А ну, ну. Вот только их применяют еще и, чтобы от обратной связи уйти.

Кто применяет?

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

K>Я подозреваю что GC-шные программы будут падать реже, но зато будут полны разными трудноуловимыми глюками.

Как показывает практика твои подозрения не соответствуют действительности.

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

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

K>>Я подозреваю что GC-шные программы будут падать реже, но зато будут полны разными трудноуловимыми глюками.

AVK>Как показывает практика твои подозрения не соответствуют действительности.

Думаю пока рано делать выводы. Все "тяжелые" программы (САПРЫ, оффисы и т.п.) которые мы юзаем пока в unmanaged коде.

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

K>Зачем городить огород? Когда и так ясно кто кем владеет.

[OffTopic]
Ну, блин, прямо рабовладельческий строй. Даешь демократию!
[/OffTopic]