Re[2]: RAII vs RAII
От: ViTech  
Дата: 20.09.18 11:59
Оценка:
Здравствуйте, dipso, Вы писали:

D>Прошу прощения, не все ответы прочитал, нет столько времени, но...

D>Самый простой вариант — реализовать класс Tree пытаясь использовать
D>нынешнию RAII идеологию. Пишу прямо в тегах, сильно не пинайте.

Если m_parent типа weakptr_type(и это правильно), то зачем в Parent()/SetParent() используется ptr_type? Попробуйте изменить на weakptr_type.

D>Нужно наследование от std::enable_shared_from_this.

D>Конструктор по умолчанию не важен.Хочу наследовать от
D>Tree. Включение против наследования не поможет.
D>Интересуют конструкторы.
D>В любом случае std::bad_weak_ptr.

Я бы не стал наследоваться от такого Tree. Но если так надо... Пишите код, с которым возникают проблемы, чтобы было от чего отталкиваться. На предположениях далеко не уедешь .
Пока сам не сделаешь...
Re[3]: RAII vs RAII
От: dipso  
Дата: 20.09.18 13:03
Оценка:
Здравствуйте, ViTech, Вы писали:

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


D>>Прошу прощения, не все ответы прочитал, нет столько времени, но...

D>>Самый простой вариант — реализовать класс Tree пытаясь использовать
D>>нынешнию RAII идеологию. Пишу прямо в тегах, сильно не пинайте.

VT>Если m_parent типа weakptr_type(и это правильно), то зачем в Parent()/SetParent() используется ptr_type? Попробуйте изменить на weakptr_type.


D>>Нужно наследование от std::enable_shared_from_this.

D>>Конструктор по умолчанию не важен.Хочу наследовать от
D>>Tree. Включение против наследования не поможет.
D>>Интересуют конструкторы.
D>>В любом случае std::bad_weak_ptr.

VT>Я бы не стал наследоваться от такого Tree. Но если так надо... Пишите код, с которым возникают проблемы, чтобы было от чего отталкиваться. На предположениях далеко не уедешь .

Ничего говорить не буду, разводить холивары.Могло бы решить переопределение в классе new.
Но кто-то на sof сказал что это не консистентность в языке. Я люблю C++, но истинного RAII так и не получится.
Re[2]: RAII vs RAII
От: rg45 СССР  
Дата: 20.09.18 16:28
Оценка:
Здравствуйте, dipso, Вы писали:

D>Прошу прощения, не все ответы прочитал, нет столько времени, но...

D>Самый простой вариант — реализовать класс Tree пытаясь использовать
D>нынешнию RAII идеологию. Пишу прямо в тегах, сильно не пинайте.

  The Original Example
D>
D>template<typename T>
D>class Tree
D>{
D>public:

D>  using ptr_type = std::shared_ptr<T>;
D>  using weakptr_type = std::weak_ptr<T>;

D>Tree(ptr_type parent)
D>{
D>  SetParent(parent);
D>}

D>ptr_type Parent()
D>{
D>  return m_parent.lock();
D>} 

D>void SetParent(ptr_type parent) 
D>{
D>  m_parent = parent;

D>}

D>private:

D>weakptr_type m_parent;
D>std::vector<ptr_type> m_children;
D>};
D>


D>Нужно наследование от std::enable_shared_from_this.

D>Конструктор по умолчанию не важен.Хочу наследовать от
D>Tree. Включение против наследования не поможет.
D>Интересуют конструкторы.
D>В любом случае std::bad_weak_ptr.

Ну теперь хоть задача понятна более-менее

И сразу хочу отметить, что я вижу как раз то, о чем говорил здесь: http://rsdn.org/forum/cpp/7249960.1
Автор: rg45
Дата: 18.09.18
. А именно, не очень удачный дизайн. Судите сами: мы имеем проблему невозможности получения в конструкторе владеющего указателя на конструируемый класс. Вопрос: почему нам нужен этот указатель? А потому, что мы так запроектировали. А что нам мешает изменить этот дизайн? Да ничего!

Выбрасываем метод SetParent, а вместо него добавляем пару методов: AddChild и CreateChild. После чего юзабельность не только не ухудшается, а становится даже лучше. И исходная проблема испаряется как сон на заре:

https://ideone.com/HypKcm

template <typename T>
class Tree : public std::enable_shared_from_this<Tree<T>>
{
public:

  template<typename...Args>
  explicit Tree(Args&&...args) : m_data(std::forward<Args>(args)...) {}
  
  std::shared_ptr<Tree> AddChild(const std::shared_ptr<Tree>& child)
  {
    using base = std::enable_shared_from_this<Tree>;
    m_children.push_back(child);
    child->m_parent = base::shared_from_this();
    return child;
  }

  template<typename...Args>
  std::shared_ptr<Tree> CreateChild(Args&&...args)
  {
    return AddChild(std::make_shared<Tree>(std::forward<Args>(args)...));
  }

private:
  T m_data;
  std::weak_ptr<Tree> m_parent;
  std::vector<std::shared_ptr<Tree>> m_children;
};

int main()
{
  const auto root_ptr = std::make_shared<Tree<int>>();
  root_ptr->CreateChild(1)->CreateChild(11)->CreateChild(111);
  root_ptr->CreateChild(2)->CreateChild(21)->CreateChild(211);
}
--
Отредактировано 20.09.2018 16:45 rg45 . Предыдущая версия . Еще …
Отредактировано 20.09.2018 16:42 rg45 . Предыдущая версия .
Отредактировано 20.09.2018 16:35 rg45 . Предыдущая версия .
Отредактировано 20.09.2018 16:33 rg45 . Предыдущая версия .
Re[3]: RAII vs RAII
От: ViTech  
Дата: 21.09.18 08:02
Оценка: 2 (2) +6 :)
Здравствуйте, rg45, Вы писали:

R>И сразу хочу отметить, что я вижу как раз то, о чем говорил здесь: http://rsdn.org/forum/cpp/7249960.1
Автор: rg45
Дата: 18.09.18
. А именно, не очень удачный дизайн. Судите сами: мы имеем проблему невозможности получения в конструкторе владеющего указателя на конструируемый класс. Вопрос: почему нам нужен этот указатель? А потому, что мы так запроектировали. А что нам мешает изменить этот дизайн? Да ничего!


Ну как что мешает... Если перепроектировать, то становится не интересно. А как же полёт фантазии, муки творчества? Передать недостроенный this в конструктор базового класса, приватно наследовать интерфейс, возможно стать владельцем себя самого. Искать RAII в C++. Грустить, что его там нет. Выбрасывается целый пласт деятельности и переживаний. Скучно живёте, товарищи .

Если всё перепроектировать, то можно дойти до чего угодно. Например, задаться вопросами: Tree уникально владеет своими children или нет? Т.е. может ли один child находиться одновременно в двух разных Tree (или ещё у кого-нибудь во владении вообще)? Точно ли тут нужен std::shared_ptr для children? И как следствие std::enable_shared_from_this для Tree. Всё же скатится в банальность .
Пока сам не сделаешь...
Re[5]: RAII vs RAII
От: Erop Россия  
Дата: 02.10.18 07:45
Оценка:
Здравствуйте, rg45, Вы писали:

R>>>Зачем вообще может понадобиться владеющий указатель в конструторе? Что можно делать с владеющим указателем на объект, время жизни которого еще не началось? Ну, допустим, получили мы его, что дальше?


R>Сырой указатель на что, на конструируемый объект? И зачем может понадобиться передавать его в базовый класс, когда его можно там без труда вычислить? Разве что, при виртуальном наследовании? Тем более не понятно, зачем может понадобиться передавать в базовый класс владеющий указатель на конструируемый объект.


shared_ptr -- это не только владеющий, но и слабый. Легко может понадобиться для подписки на уведомления какие-нибудь, например...

Если клиентом подписки будет RAII, то придётся подписывемый объект из этого клиента выводить и мутить какие-то вирт. методы, или делать подписку в две стадии, или таки передавать в конструктор клиента подписки this на недоделанный объект...

Скажем, пусть у нас подписчик шаблонный, определяется типом сокета, к которому подписывется (прототип входа/выхода или std::function, например), и в конструктор получает сокет и коллбэк.
Удобно было бы сделать подписчик полем, и в его конструктор передать сокет и лямбду...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Отредактировано 02.10.2018 8:03 Erop . Предыдущая версия .
Re[6]: RAII vs RAII
От: Кодт Россия  
Дата: 02.10.18 10:06
Оценка:
Здравствуйте, Erop, Вы писали:

E>Если клиентом подписки будет RAII, то придётся подписывемый объект из этого клиента выводить и мутить какие-то вирт. методы, или делать подписку в две стадии, или таки передавать в конструктор клиента подписки this на недоделанный объект...


Вот это всё — лишний раз показывает, что очень зря в плюсах нет двухфазной инициализации из коробки. И каждый раз там, где она нужна, её велосипедят.
Перекуём баги на фичи!
Re[7]: RAII vs RAII
От: Erop Россия  
Дата: 02.10.18 10:43
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Вот это всё — лишний раз показывает, что очень зря в плюсах нет двухфазной инициализации из коробки. И каждый раз там, где она нужна, её велосипедят.


Да она просто дороже. И её ничто не мешает на библиотеке сделать. Нет проблем.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re: RAII vs RAII
От: CEMb  
Дата: 04.10.18 03:05
Оценка:
Здравствуйте, dipso, Вы писали:

D>Но std::enable_shared_from_this::shared_from_this нельзя использовать в конструкТОРАХ.


D>Ладно у кого какие варианты7


Редкий случай, но если надо, я использую weak_ptr внутри класса на самого себя. Т.е. тот, кто создал объект, потом ему указатель прописывает, +1 строчка в функции. Раньше использовал shared_from_this, но это немного неочевидная штука, потому что shared_ptr создаётся снаружи и управление объектом поручать самому объекту немного неправильно (delete this посреди поля).
В идеальной ситуации сам объект не должен выдавать shared_ptr на себя. Т.е. надо пересмотреть архитектуру.
Re[4]: RAII vs RAII
От: dipso  
Дата: 04.10.18 17:19
Оценка:
Здравствуйте, ViTech, Вы писали:

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


R>>И сразу хочу отметить, что я вижу как раз то, о чем говорил здесь: http://rsdn.org/forum/cpp/7249960.1
Автор: rg45
Дата: 18.09.18
. А именно, не очень удачный дизайн. Судите сами: мы имеем проблему невозможности получения в конструкторе владеющего указателя на конструируемый класс. Вопрос: почему нам нужен этот указатель? А потому, что мы так запроектировали. А что нам мешает изменить этот дизайн? Да ничего!


VT>Ну как что мешает... Если перепроектировать, то становится не интересно. А как же полёт фантазии, муки творчества? Передать недостроенный this в конструктор базового класса, приватно наследовать интерфейс, возможно стать владельцем себя самого. Искать RAII в C++. Грустить, что его там нет. Выбрасывается целый пласт деятельности и переживаний. Скучно живёте, товарищи .


VT>Если всё перепроектировать, то можно дойти до чего угодно. Например, задаться вопросами: Tree уникально владеет своими children или нет? Т.е. может ли один child находиться одновременно в двух разных Tree (или ещё у кого-нибудь во владении вообще)? Точно ли тут нужен std::shared_ptr для children? И как следствие std::enable_shared_from_this для Tree. Всё же скатится в банальность .


Ну да, да, да.
Вот вариант двуфакторной инициализации. Мне важно ваше мнение.
Re[2]: RAII vs RAII
От: dipso  
Дата: 04.10.18 17:44
Оценка:
CEM>Редкий случай, но если надо, я использую weak_ptr внутри класса на самого себя. Т.е. тот, кто создал объект, потом ему указатель прописывает, +1 строчка в функции. Раньше использовал shared_from_this, но это немного неочевидная штука, потому что shared_ptr создаётся снаружи и управление объектом поручать самому объекту немного неправильно (delete this посреди поля).
CEM>В идеальной ситуации сам объект не должен выдавать shared_ptr на себя. Т.е. надо пересмотреть архитектуру.

Здесь проблема передечи своего this кому-то в базовом классе. Ну типа передать себя родителю. Поэтому, даже AddChild не поможет, поскольку enable_shared_from_this всё равно даст std::bad_weak_ptr.Т.е нуна чёб отработали все крнструктора. Потому и two-facktor-initialization. Вопрос — можно ли средствами языка заставить людей не создавать объекты на стеке. Ну всем же нужны std::shared_ptr's ...
Re[2]: RAII vs RAII
От: dipso  
Дата: 04.10.18 17:58
Оценка:
Здравствуйте, CEMb, Вы писали:

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


D>>Но std::enable_shared_from_this::shared_from_this нельзя использовать в конструкТОРАХ.


D>>Ладно у кого какие варианты7


CEM>Редкий случай, но если надо, я использую weak_ptr внутри класса на самого себя. Т.е. тот, кто создал объект, потом ему указатель прописывает, +1 строчка в функции. Раньше использовал shared_from_this, но это немного неочевидная штука, потому что shared_ptr создаётся снаружи и управление объектом поручать самому объекту немного неправильно (delete this посреди поля).

CEM>В идеальной ситуации сам объект не должен выдавать shared_ptr на себя. Т.е. надо пересмотреть архитектуру.
Не надо пересматривать архитектуру в общем. Здесь просто языковая зоковыка которую надо обойти. Да, ту самую RAII, о которой говорят на каждом сиплюсплюс углу, заменить на двухфакторную инициализацию, у которой самой рогожки и ножки, если вы адепт чистого пламенного "встандартепрописсанного" два плюса)))
Re[3]: RAII vs RAII
От: dipso  
Дата: 04.10.18 19:22
Оценка:
Здравствуйте, dipso, Вы писали:

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


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


D>>>Но std::enable_shared_from_this::shared_from_this нельзя использовать в конструкТОРАХ.


D>>>Ладно у кого какие варианты7


CEM>>Редкий случай, но если надо, я использую weak_ptr внутри класса на самого себя. Т.е. тот, кто создал объект, потом ему указатель прописывает, +1 строчка в функции. Раньше использовал shared_from_this, но это немного неочевидная штука, потому что shared_ptr создаётся снаружи и управление объектом поручать самому объекту немного неправильно (delete this посреди поля).

CEM>>В идеальной ситуации сам объект не должен выдавать shared_ptr на себя. Т.е. надо пересмотреть архитектуру.
D>Не надо пересматривать архитектуру в общем. Здесь просто языковая зоковыка которую надо обойти. Да, ту самую RAII, о которой говорят на каждом сиплюсплюс углу, заменить на двухфакторную инициализацию, у которой самой рогожки и ножки, если вы адепт чистого пламенного "встандартепрописсанного" два плюса)))
Зто уже политический вопрос, надеюсь, мы будем от них долеки.
Re[3]: RAII vs RAII
От: B0FEE664  
Дата: 05.10.18 08:22
Оценка: +2
Здравствуйте, dipso, Вы писали:

D> Вопрос — можно ли средствами языка заставить людей не создавать объекты на стеке.

Да.
И каждый день — без права на ошибку...
Re[3]: RAII vs RAII
От: CEMb  
Дата: 08.10.18 04:25
Оценка:
Здравствуйте, dipso, Вы писали:

D>Здесь проблема передечи своего this кому-то в базовом классе. Ну типа передать себя родителю. Поэтому, даже AddChild не поможет, поскольку enable_shared_from_this всё равно даст std::bad_weak_ptr.Т.е нуна чёб отработали все крнструктора. Потому и two-facktor-initialization. Вопрос — можно ли средствами языка заставить людей не создавать объекты на стеке. Ну всем же нужны std::shared_ptr's ...


//...
private:
    Child();
friend shered_ptr<Child>(); // или как-то так, не помню.

//...
template <typename Child> void Parent::Creare ()
{
    shared_prt<Child> child = make_shared<Child>();
    if (child)
    { //..
    }
}

Примерно так?
Конструкторы все отработали, указатель у родителя.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.