Здравствуйте, samius, Вы писали:
S>Как-то странно. Вроде язык высокоуровневый считается, куча умных контейнеров и указателей в библиотеках.. А как доходит до банального дерева — приходится выпиливать его руками с нуля

Если тебе не важна супер-эффективность, то просто пишешь дерево на массиве shared_ptr детей и всё.
Если дерево надо прошить, то добавляешь регистрацию/отписывание родителя в детях.

А вот если ты начинаешь считать ресурсы и жёстко экономить, то тут уже надо подробностями заморочиться...

В каком-то смысле это не обязанность, а возможность

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

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

R>>Согласен, так ещё лучше.

S>А чем лучше?

S>Как-то странно. Вроде язык высокоуровневый считается, куча умных контейнеров и указателей в библиотеках.. А как доходит до банального дерева — приходится выпиливать его руками с нуля

Основная сила С++ в том, что можно и так и так.
Если делаешь прототип или утилиту, то используешь std::vector, выделяешь всё по new и не удаляешь (получается настоящий GC).
А если тебе надо будет этим парсить 100-мегабайтный XML в DOM, то тут интрузивные линки, и region аллокатор огого как пригодятся.

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

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

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

C>Объект считается мёртвым, как только начал выполняться его деструктор.
Т.е. методы, вызванные из деструктора, выполняются уже у мертвого объекта?

Да не, я не против. Просто нашел это странным.

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

E>Здравствуйте, samius, Вы писали:
S>>Как-то странно. Вроде язык высокоуровневый считается, куча умных контейнеров и указателей в библиотеках.. А как доходит до банального дерева — приходится выпиливать его руками с нуля

E>Если тебе не важна супер-эффективность, то просто пишешь дерево на массиве shared_ptr детей и всё.
на данном этапе не нужна, да и вообще вряд ли.

E>Если дерево надо прошить, то добавляешь регистрацию/отписывание родителя в детях.
Что значит прошить?

E>А вот если ты начинаешь считать ресурсы и жёстко экономить, то тут уже надо подробностями заморочиться...

E>В каком-то смысле это не обязанность, а возможность

Ясно. Но тему я завел еще и что бы понять, как борются с рисками использования смартпоинтеров (вроде пересоздания shared_ptr по одному адресу T*).
Т.е. пока мне чихать на эффективность до той степени что я могу себе позволить вектора shared_ptr. Стоит ли (принято ли) в таких случаях заморачиваться упрятыванием указателей T* от греха подальше? Либо все лечится дисциплиной и передачей исключительно shared_ptr<T> по ссылке либо по значению?
Например в гвайде гугла рекомендуют воздерживаться от shared_ptr (но по другим причинам).

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

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

S>>Как-то странно. Вроде язык высокоуровневый считается, куча умных контейнеров и указателей в библиотеках.. А как доходит до банального дерева — приходится выпиливать его руками с нуля

R>Основная сила С++ в том, что можно и так и так.
R>Если делаешь прототип или утилиту, то используешь std::vector, выделяешь всё по new и не удаляешь (получается настоящий GC).
R>А если тебе надо будет этим парсить 100-мегабайтный XML в DOM, то тут интрузивные линки, и region аллокатор огого как пригодятся.
Максимум мегабайтный, но на камне в 200MHz. Сейчас основная проблема заключается в скорости создания прототипа. А я итак закис в деталях

R>
:кефир:

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

S>Допустим, требуется организовать дерево с указателями на родителей. shared_ptr<T> — то что доктор прописал по этому поводу:
S>

S>class Node
S>{
S>    vector< shared_ptr<Node> > _children;
S>    weak_ptr<Node> _parent;
S>    ...
S>};
S>

В htmlayout/sciter дерево DOM объектов устроено таким образом:

class node: public ref_counted
{
  node* parent;
  collection< handle<node> > children;
};

Где handle<node> это smart ptr — делает ref_counted::add_ref/release при установке/очистке.
Делал это все руками ибо не нашел в stl в свое время подходящей идиомы которая позволяла бы это делать с той же эффективностью.

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

E>>Если дерево надо прошить, то добавляешь регистрацию/отписывание родителя в детях.
S>Что значит прошить?

Добавить детям указатель на родителя.

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


S>Т.е. пока мне чихать на эффективность до той степени что я могу себе позволить вектора shared_ptr. Стоит ли (принято ли) в таких случаях заморачиваться упрятыванием указателей T* от греха подальше? Либо все лечится дисциплиной и передачей исключительно shared_ptr<T> по ссылке либо по значению?

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

S>Например в гвайде гугла рекомендуют воздерживаться от shared_ptr (но по другим причинам).
Ну мне он тоже не нравится.