weak_ptr и this

[sVasilich]

Допустим, есть следующий код:

class B;

class A {
public:
    A();
    ~A();

private:

    B* ptrB;

};

class B {

public:
    B(A* _a);
    ~B();

private:
    A* ptrA;
};

A::A() {
    ptrB = new B(this);
}

A::~A() {
    delete ptrB;
}

B::B(A *_a) {
    ptrA = _a;
}

B::~B() {
    ptrA = NULL;
}

Задача: заменить обычные указатели на интеллектуальные. В классе A используется std::shared_ptr, в классе B - std::weak_ptr.

Как правильно реализовать конструктор класса B?

class B;

class A {
public:
    A();
    ~A();

private:
    std::shared_ptr<B> ptrB;

};

class B {

public:
    B(/*????*/);
    ~B();

private:
    std::weak_ptr<A> ptrA;
};

A::A() {
    ptrB = std::shared_ptr<B>(new B(/*???*/));
}

A::~A() {
}

B::B(/*????*/) {
    //????
}

B::~B() {
}

[pproger]

2sVasilich
если ты собрался в классах использовать умные указатели, ссылающиеся друг на друга, тебе сначала нужно где-то создать объекты этих классов.
можно сделать например так:

#include <iostream>

#include <boost/shared_ptr.hpp>
#include <boost/weak_ptr.hpp>

using boost::shared_ptr;
using boost::weak_ptr;
using namespace std;

class B;

class A {
public:
	~A() {
		cout << "A::~A" << endl;
	}

	void setB(const shared_ptr<B> &b) {
		ptrB = b;
	}

private:
	shared_ptr<B> ptrB;
};

class B {
public:
	~B() {
		cout << "B::~B" << endl;
	}

	void setA(const shared_ptr<A> &a) {
		ptrA = a;
	}

private:
	weak_ptr<A> ptrA;
};

int main()
{
	shared_ptr<A> a(new A);
	shared_ptr<B> b(new B);

	a->setB(b);
	b->setA(a);

	return 0;
}

[sVasilich]

pproger, спасибо за ответ.

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

Т.е. есть родительский объект, у него есть дочерний объект. Родительский объект об этом знает. Дочерний объект знает о своём родителе. Вне родителя дочерний объект не виден.

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

void B::crash() {
    delete ptrA;
}

Как правильно поступить в таком случае?

[Rififi]

sVasilich

Задача: заменить обычные указатели на интеллектуальные. В классе A используется std::shared_ptr, в классе B - std::weak_ptr.

struct Child;

struct Parent : public boost::enable_shared_from_this<Parent>
{
	void CreateChild();
	boost::shared_ptr<Child> child_;
};

struct Child
{
	Child(boost::shared_ptr<Parent> parent) : parent_(parent) {}
	boost::weak_ptr<Parent> parent_;
};

void Parent::CreateChild()
{
	child_.reset(new Child(shared_from_this()));
}

boost::shared_ptr<Parent> parent(new Parent());
parent->CreateChild();

[Rififi]

sVasilich

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

Пытаться забить гвозди микроскопом - это дело конечно очень весёлое...
Но нормальные люди добиваются той же задачи делая деструктор закрытым :lol:

[sVasilich]

Rififi, спасибо, то что нужно!
Про enable_shared_from_this я нагуглил, но с использованием не разобрался, теперь понятнее.

Но нормальные люди добиваются той же задачи делая деструктор закрытым :lol:
А можно про правильный способ забивания гвоздей на примере? Как потом вызывается деструктор, когда нужно действительно удалить родителя?

[_Bers]

Сообщение от sVasilich

Но нормальные люди добиваются той же задачи делая деструктор закрытым :lol:
А можно про правильный способ забивания гвоздей на примере? Как потом вызывается деструктор, когда нужно действительно удалить родителя?

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

Но почитав тред, понял: в конкретно данной ситуации его существование излишне.

Ребенок не самостоятелен. Он - собственность родителя. Нет родителя - нет детей.

Родитель держит сильный указатель на детей. Дети держат сырой указатель на родителя.

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

При разрушении Родителя, сильные указатели автоматически ликвидируют детей.

Вместо сильного можно использовать unique_ptr.

Хотя лично я предпочитаю иметь дело с как можно меньшим количеством сущностей в коде.

На моей практике shared_ptr покрывает всю область применения указателей.

Ни разу не сталкивался с ситуацией, когда кроме него потребовался бы ещё какой нибудь.


Что касается закрытых диструкторов: детенка объявляет родителя другом. Теперь только родитель сможет ликвидировать дитенку. Больше никто.

Но в этом нет никакого смысла, ибо кроме родителя все равно никто к детенке доступа не имеет.

Можно закрыть диструктор родителя, что бы его "ничайно" не прибил детенка. Однако, делать защиту от саботажа (ну или от дибилов) - напрасное усложнение кода и трата времени.

На верхнем (уровень бизнес-логики) уровне самостоятельное использование new/delete - признак говнокода.

[sVasilich]

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

По идее, в этой ситуации (пост 2):

	shared_ptr<A> a(new A);
	shared_ptr<B> b(new B);

	a->setB(b);
	b->setA(a);

если в A и B будут shared_ptr, получится циклическая зависимость и память освобождена не будет.. я так понял.

Можно закрыть диструктор родителя, что бы его "ничайно" не прибил детенка.

Вот здесь интересно, кто будет вызывать деструктор родителя? Нужно будет делать дружетсвенный shared_ptr<Parent>, я правильно понял? Другого варианта пока не вижу...

Родитель держит сильный указатель на детей. Дети держат сырой указатель на родителя.

Т.е. в таком контексте использовать сырые указатели хорошо и правильно, ответственность за него ложится полностью на клиента? Как я понял, weak_ptr как раз и есть защита от саботажа и дебилов.

На верхнем (уровень бизнес-логики) уровне самостоятельное использование new/delete - признак говнокода.

Другими словами:

Parent* pt = new Parent() //плохо

...

Parent() {
  mChild = new Child(); //вполне допустимо
}

?

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

[_Bers]

Сообщение от sVasilich

если в A и B будут shared_ptr, получится циклическая зависимость и память освобождена не будет.. я так понял.

В данном случае умный указатель нужен только родителю на детей.

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

Всегда был только один хозяин, который владел ресурсами. Но никогда ресурсы не владели своим хозяином.

В чужом коде встречал, да. Но там налицо было переусложнение кода.
Так, словно архитектура была создана ради архитектуры, а не для решения задач насущных.

Сообщение от sVasilich

Вот здесь интересно, кто будет вызывать деструктор родителя?

Я не телепат. Откуда я знаю, кто владеет вашим родителем.

Сообщение от sVasilich

Нужно будет делать дружетсвенный shared_ptr<Parent>, я правильно понял? Другого варианта пока не вижу...

Не понял момента. Зачем делать дружественный shared_ptr<Parent>?

Сообщение от sVasilich

Т.е. в таком контексте использовать сырые указатели хорошо и правильно, ответственность за него ложится полностью на клиента? Как я понял, weak_ptr как раз и есть защита от саботажа и дебилов.

Клиенты, то бишь те самые детишки, которые держат сырой указатель, используют его только и только для доступа к объекту.
Ничего другого они с ним больше не делают.

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

Но и без этого во всех книжках пишут: кто выделял, тот и должен удалять, или получится каша.

Делать защиту от дибилов - глупо.
От саботажа - ещё глупее.

Сообщение от sVasilich

Другими словами:

Parent* pt = new Parent() //плохо
...
Parent() {
  mChild = new Child(); //вполне допустимо
}

?

Нет. Оби ситуации плохи. Потому что в обеих используется new.

Когда я пишу: "не нужно использовать низкоуровневую работу с выделением/освобождением памяти на уровне бизнес-логики приложения", то я имею ввиду вообще не использовать операторы new/delete

Если нужно создавать объекты в куче, к вашим услугам контейнера, которые сделают это все за вас:

std::vector<Some> vec;
vec.push_back( Some(param) );
...

shared_ptr<Some> smart1 = make_shared<Some>(param);
...
shared_ptr<ISome> smart2 = make_shared<Some>(param);

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

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

В вашем случае ребенку можно предоставить сырой указатель.
Слабый указатель в этой ситуации избыточен.

[sVasilich]

_Bers, спасибо, теперь всё стало на свои места.

Я не телепат. Откуда я знаю, кто владеет вашим родителем.

Не понял момента. Зачем делать дружественный shared_ptr<Parent>?

Неправильно выразился. Я хотел сказать, что владелец родителя должен быть дружественным по отношении к нему. Если создаём Parent в main(), то непонятно кто его будет удалять. Поэтому и пришла в голову обёртка в виде дружественного shared_ptr<Parent>. В общем, по этому вопросу мне всё понятно.

Кхм.. Последний кусок кода, это мне уже видно спать хотелось Конечно же должно быть:

Parent() {
   mChild = std::sgared_ptr<Child>(new Child(this));
}

Child(Parent* _parent) {
  parentPtr = _parent;
}

Ещё раз спасибо всем, кто принял участие в теме.