Здравствуйте, 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. Но если так надо... Пишите код, с которым возникают проблемы, чтобы было от чего отталкиваться. На предположениях далеко не уедешь .
Здравствуйте, 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 так и не получится.
Здравствуйте, dipso, Вы писали: D>Прошу прощения, не все ответы прочитал, нет столько времени, но... D>Самый простой вариант — реализовать класс Tree пытаясь использовать D>нынешнию RAII идеологию. Пишу прямо в тегах, сильно не пинайте.
D>Нужно наследование от std::enable_shared_from_this. D>Конструктор по умолчанию не важен.Хочу наследовать от D>Tree. Включение против наследования не поможет. D>Интересуют конструкторы. D>В любом случае std::bad_weak_ptr.
. А именно, не очень удачный дизайн. Судите сами: мы имеем проблему невозможности получения в конструкторе владеющего указателя на конструируемый класс. Вопрос: почему нам нужен этот указатель? А потому, что мы так запроектировали. А что нам мешает изменить этот дизайн? Да ничего!
Выбрасываем метод SetParent, а вместо него добавляем пару методов: AddChild и CreateChild. После чего юзабельность не только не ухудшается, а становится даже лучше. И исходная проблема испаряется как сон на заре:
. А именно, не очень удачный дизайн. Судите сами: мы имеем проблему невозможности получения в конструкторе владеющего указателя на конструируемый класс. Вопрос: почему нам нужен этот указатель? А потому, что мы так запроектировали. А что нам мешает изменить этот дизайн? Да ничего!
Ну как что мешает... Если перепроектировать, то становится не интересно. А как же полёт фантазии, муки творчества? Передать недостроенный this в конструктор базового класса, приватно наследовать интерфейс, возможно стать владельцем себя самого. Искать RAII в C++. Грустить, что его там нет. Выбрасывается целый пласт деятельности и переживаний. Скучно живёте, товарищи .
Если всё перепроектировать, то можно дойти до чего угодно. Например, задаться вопросами: Tree уникально владеет своими children или нет? Т.е. может ли один child находиться одновременно в двух разных Tree (или ещё у кого-нибудь во владении вообще)? Точно ли тут нужен std::shared_ptr для children? И как следствие std::enable_shared_from_this для Tree. Всё же скатится в банальность .
Здравствуйте, rg45, Вы писали:
R>>>Зачем вообще может понадобиться владеющий указатель в конструторе? Что можно делать с владеющим указателем на объект, время жизни которого еще не началось? Ну, допустим, получили мы его, что дальше?
R>Сырой указатель на что, на конструируемый объект? И зачем может понадобиться передавать его в базовый класс, когда его можно там без труда вычислить? Разве что, при виртуальном наследовании? Тем более не понятно, зачем может понадобиться передавать в базовый класс владеющий указатель на конструируемый объект.
shared_ptr -- это не только владеющий, но и слабый. Легко может понадобиться для подписки на уведомления какие-нибудь, например...
Если клиентом подписки будет RAII, то придётся подписывемый объект из этого клиента выводить и мутить какие-то вирт. методы, или делать подписку в две стадии, или таки передавать в конструктор клиента подписки this на недоделанный объект...
Скажем, пусть у нас подписчик шаблонный, определяется типом сокета, к которому подписывется (прототип входа/выхода или std::function, например), и в конструктор получает сокет и коллбэк.
Удобно было бы сделать подписчик полем, и в его конструктор передать сокет и лямбду...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Если клиентом подписки будет RAII, то придётся подписывемый объект из этого клиента выводить и мутить какие-то вирт. методы, или делать подписку в две стадии, или таки передавать в конструктор клиента подписки this на недоделанный объект...
Вот это всё — лишний раз показывает, что очень зря в плюсах нет двухфазной инициализации из коробки. И каждый раз там, где она нужна, её велосипедят.
Здравствуйте, Кодт, Вы писали:
К>Вот это всё — лишний раз показывает, что очень зря в плюсах нет двухфазной инициализации из коробки. И каждый раз там, где она нужна, её велосипедят.
Да она просто дороже. И её ничто не мешает на библиотеке сделать. Нет проблем.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, dipso, Вы писали:
D>Но std::enable_shared_from_this::shared_from_this нельзя использовать в конструкТОРАХ.
D>Ладно у кого какие варианты7
Редкий случай, но если надо, я использую weak_ptr внутри класса на самого себя. Т.е. тот, кто создал объект, потом ему указатель прописывает, +1 строчка в функции. Раньше использовал shared_from_this, но это немного неочевидная штука, потому что shared_ptr создаётся снаружи и управление объектом поручать самому объекту немного неправильно (delete this посреди поля).
В идеальной ситуации сам объект не должен выдавать shared_ptr на себя. Т.е. надо пересмотреть архитектуру.
Здравствуйте, ViTech, Вы писали:
VT>Здравствуйте, rg45, Вы писали:
R>>И сразу хочу отметить, что я вижу как раз то, о чем говорил здесь: http://rsdn.org/forum/cpp/7249960.1
. А именно, не очень удачный дизайн. Судите сами: мы имеем проблему невозможности получения в конструкторе владеющего указателя на конструируемый класс. Вопрос: почему нам нужен этот указатель? А потому, что мы так запроектировали. А что нам мешает изменить этот дизайн? Да ничего!
VT>Ну как что мешает... Если перепроектировать, то становится не интересно. А как же полёт фантазии, муки творчества? Передать недостроенный this в конструктор базового класса, приватно наследовать интерфейс, возможно стать владельцем себя самого. Искать RAII в C++. Грустить, что его там нет. Выбрасывается целый пласт деятельности и переживаний. Скучно живёте, товарищи .
VT>Если всё перепроектировать, то можно дойти до чего угодно. Например, задаться вопросами: Tree уникально владеет своими children или нет? Т.е. может ли один child находиться одновременно в двух разных Tree (или ещё у кого-нибудь во владении вообще)? Точно ли тут нужен std::shared_ptr для children? И как следствие std::enable_shared_from_this для Tree. Всё же скатится в банальность .
Ну да, да, да.
Вот вариант двуфакторной инициализации. Мне важно ваше мнение.
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 ...
Здравствуйте, 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, о которой говорят на каждом сиплюсплюс углу, заменить на двухфакторную инициализацию, у которой самой рогожки и ножки, если вы адепт чистого пламенного "встандартепрописсанного" два плюса)))
Здравствуйте, 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, о которой говорят на каждом сиплюсплюс углу, заменить на двухфакторную инициализацию, у которой самой рогожки и ножки, если вы адепт чистого пламенного "встандартепрописсанного" два плюса)))
Зто уже политический вопрос, надеюсь, мы будем от них долеки.
Здравствуйте, 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)
{ //..
}
}
Примерно так?
Конструкторы все отработали, указатель у родителя.