Как избежать или предусмотреть способ отлова проблем циклических ссылок, при использовании умных указателей с подсчётом ссылок.

Здравствуйте, Аноним, Вы писали:

А>Как избежать или предусмотреть способ отлова проблем циклических ссылок, при использовании умных указателей с подсчётом ссылок.

Это как так циклические ссылки при использовании умных указателей?

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

D>Здравствуйте, Аноним, Вы писали:

А>>Как избежать или предусмотреть способ отлова проблем циклических ссылок, при использовании умных указателей с подсчётом ссылок.

D>Это как так циклические ссылки при использовании умных указателей?

class A
{
   Ptr<B> b_;
};

class B
{
   Ptr<A> a_;
};

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

D>Здравствуйте, Аноним, Вы писали:

А>>Как избежать или предусмотреть способ отлова проблем циклических ссылок, при использовании умных указателей с подсчётом ссылок.

D>Это как так циклические ссылки при использовании умных указателей?

Или ты имеешь в виду, что указатели недостаточно умные?

Здравствуйте, Аноним, Вы писали:

А>Как избежать или предусмотреть способ отлова проблем циклических ссылок, при использовании умных указателей с подсчётом ссылок.

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

> Как избежать или предусмотреть способ отлова проблем циклических ссылок, при использовании умных указателей с подсчётом ссылок.

Умные указатели тебе здесь не помогут. Используй GC — это единственная задача, для чего он хорош.

--
Maxim Yegorushkin

Здравствуйте, <Аноним>, Вы писали:

А>Как избежать или предусмотреть способ отлова проблем циклических ссылок, при использовании умных указателей с подсчётом ссылок.

Убивать на корню...

template<class T>
class CUmniyPtr
{
private:
    T* p;
    ...
public:
    ...
    CUmniyPtr<T>& operator =(const CUmniyPtr<T>& src)
    {
        ASSERT(p != NULL ? (src.p != p) : TRUE);
        ...
    }
};

Но вот если p — видоизменяется, то задача, пожалуй, не имеет решения в общем случае

Здравствуйте, Аноним, Вы писали:

А>Как избежать или предусмотреть способ отлова проблем циклических ссылок, при использовании умных указателей с подсчётом ссылок.

разделяешь взаимно ссылающиеся объекты на главные и подчиненные
одни ссылаются через boost::shared_ptr, другие — через boost::weak_ptr

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Вадим Никулин, Вы писали:

ВН>Здравствуйте, Аноним, Вы писали:

А>>Как избежать или предусмотреть способ отлова проблем циклических ссылок, при использовании умных указателей с подсчётом ссылок.

ВН>Нужно пытаться веделить "главный объект", все ссылки только выходят из него. На него ссылаются только из вне.

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

class A {
public:
smart_ptr<A> Member;
}

class B {
public:
smart_ptr<A> bMember;
}

class C {
public:
smart_ptr<A> cMember;
}

A obj;
A obj1;
B obj2;
C obj3;

//Простенький цикл можно ограничит создав метод SetMember с соотв. проверкой
obj.Member = obj1;
obj1.Member = obj;

//А вот тут как быть
obj.Member = obj1;
obj1.Member = obj2;
obj2.bMember = obj3;
obj3.cMember = obj;