При попытке перевести все на язык смартов возникают трудности: если делать на unique_ptr (что достаточно логично), то непонятно, как быть с указателем на родителя. Если же делать на shared_ptr / weak_ptr, то нарушается логика владения. Как в таком случае быть?
p.s. T4r4sB, это же вы, по-моему, недавно говорили, что raw-ptr устарели
Здравствуйте, _hum_, Вы писали:
__>Раньше на raw-ptr узел дерева, если говорить о двоичном варианте, выглядел
__>При попытке перевести все на язык смартов возникают трудности: если делать на unique_ptr (что достаточно логично), то непонятно, как быть с указателем на родителя. Если же делать на shared_ptr / weak_ptr, то нарушается логика владения. Как в таком случае быть?
Предлагаю "ход конём". Заменить указатели на индексы в массиве.
enum { NONE = -1 };
typedef int NODE; //!< Узел дереваtypedef int ATTR; //!< Атрибут узлаclass Document
{
... ...
struct NodeInfo
{
NAMEREF name; // Ссылка на имя
NODE next, // Следующий
prev, // Предыдущий
parent, // Родительский узел
child; // Первый дочерний узел
ATTR attr; // Первый атрибут узла
VALREF value; // Ссылка на значение
NodeInfo()
: name(NONE)
, next(NONE), prev(NONE)
, parent(NONE), child(NONE)
, attr(NONE), value(NONE) {}
};
typedef std::vector<NodeInfo> TNodes;
// ------------------------------------------------------------------
NODE m_RootNode; // Корневой узел
NODE m_NodeFreeList; // Список удаленных узлов
TNodes m_InfoNode; // Свойства узлов
... ...
};
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Здравствуйте, _hum_, Вы писали:
__>>Раньше на raw-ptr узел дерева, если говорить о двоичном варианте, выглядел
__>>При попытке перевести все на язык смартов возникают трудности: если делать на unique_ptr (что достаточно логично), то непонятно, как быть с указателем на родителя. Если же делать на shared_ptr / weak_ptr, то нарушается логика владения. Как в таком случае быть?
SVZ>Предлагаю "ход конём". Заменить указатели на индексы в массиве.
ну, тогда ж придется писать аналог менеждера кучи (чтоб искал свободное место, куда можно вставлять новые элементы, чтобы помечал удаленные как свободные места и т.п.). но еще чуть-чуть, и я психану и все же наверное так и сделаю, потому что тратить столько времени на реализацию обычного дерева — это уж слишком (а я уже третий день с этим вожусь)
SVZ>Забесплатно получаем дешевую бинарную сериализацию.
да, именно из-за нее вся возня со смартами (cereal не умеет выполнять сериализацию для raw-ptr — только для смартов)
Здравствуйте, _hum_, Вы писали:
__>При попытке перевести все на язык смартов возникают трудности: если делать на unique_ptr (что достаточно логично), то непонятно, как быть с указателем на родителя. Если же делать на shared_ptr / weak_ptr, то нарушается логика владения. Как в таком случае быть?
Понятия не имею, как какие указатели в вашем волшебном языке называются, но по логике вещей, родитель владеет детьми, но не наоборот. Т.е., указатели "вниз" и "вверх" должны быть разными.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, _hum_, Вы писали:
__>>При попытке перевести все на язык смартов возникают трудности: если делать на unique_ptr (что достаточно логично), то непонятно, как быть с указателем на родителя. Если же делать на shared_ptr / weak_ptr, то нарушается логика владения. Как в таком случае быть?
Pzz>Понятия не имею, как какие указатели в вашем волшебном языке называются, но по логике вещей, родитель владеет детьми, но не наоборот. Т.е., указатели "вниз" и "вверх" должны быть разными.
Здравствуйте, _hum_, Вы писали:
SVZ>>Предлагаю "ход конём". Заменить указатели на индексы в массиве.
__>ну, тогда ж придется писать аналог менеждера кучи (чтоб искал свободное место, куда можно вставлять новые элементы, чтобы помечал удаленные как свободные места и т.п.). но еще чуть-чуть, и я психану и все же наверное так и сделаю, потому что тратить столько времени на реализацию обычного дерева — это уж слишком (а я уже третий день с этим вожусь)
Удаленные узлы помещаются в односвязный список, голова которого хранится в m_NodeFreeList.
Хранить можно и плоский список, и целые поддеревья (только в makeNode придется этот факт учитывать), в общем пространство для маневра обширное.
Свой код не привожу, потому что у меня там хитрое владение именами узлов — не думаю, что тебе это пригодится.
По сложности — задачка на пару часов для студента 2 курса.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, _hum_, Вы писали:
Pzz>>Понятия не имею, как какие указатели в вашем волшебном языке называются, но по логике вещей, родитель владеет детьми, но не наоборот. Т.е., указатели "вниз" и "вверх" должны быть разными.
__>так точно. в этом и проблема.
Ну а почему бы не использовать для них разные типы?
Здравствуйте, _hum_, Вы писали:
__>p.s. T4r4sB, это же вы, по-моему, недавно говорили, что raw-ptr устарели
Ну если ты пишешь контейнер, в котором сам управляешь памятью, то таки придётся с ними повозиться.
Для дерева достаточно юников на потомков и сырого на родителя. Да, сырого на родителя. Да, если он не будет владеть и его время жизни меньше, чем у указуемого объекта, то можно и сырой, ничего не случится.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
__>При попытке перевести все на язык смартов возникают трудности: если делать на unique_ptr (что достаточно логично), то непонятно, как быть с указателем на родителя. Если же делать на shared_ptr / weak_ptr, то нарушается логика владения. Как в таком случае быть?
__>p.s. T4r4sB, это же вы, по-моему, недавно говорили, что raw-ptr устарели
Здравствуйте, Stanislav V. Zudin, Вы писали: SVZ>Здравствуйте, _hum_, Вы писали: SVZ>>>Предлагаю "ход конём". Заменить указатели на индексы в массиве. __>>ну, тогда ж придется писать аналог менеждера кучи (чтоб искал свободное место, куда можно вставлять новые элементы, чтобы помечал удаленные как свободные места и т.п.). но еще чуть-чуть, и я психану и все же наверное так и сделаю, потому что тратить столько времени на реализацию обычного дерева — это уж слишком (а я уже третий день с этим вожусь) SVZ>Ох уж эта молодёжь... SVZ>Вот получение узла из "менеджера кучи":
SVZ>Удаленные узлы помещаются в односвязный список, голова которого хранится в m_NodeFreeList. SVZ>Хранить можно и плоский список, и целые поддеревья (только в makeNode придется этот факт учитывать), в общем пространство для маневра обширное. SVZ>Свой код не привожу, потому что у меня там хитрое владение именами узлов — не думаю, что тебе это пригодится. SVZ>По сложности — задачка на пару часов для студента 2 курса.
я уже все это писал раньше (я не молодежь), потому-то мне и лень было заново этим заниматься думал, с новым стандартом все это донельзя упростится — фигушки.
(и там же нюансы полезут с тем, что делать, если у сохраняемого типа нет конструктора по умолчанию — придется этими всеми списками инициализации и прочей мудатеньню заниматься.к тому же придется решать вопросы, которые больше всего не люблю — организационные — какое хранилище выбрать — статическое или динамически расширяемое, делать общий случай с темплейтами или конкретный, какие названия давать и т.п.). в общем, пока оставалась надежда выкрутиться малой кровью, но кажется, она на исходе
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, _hum_, Вы писали:
__>>p.s. T4r4sB, это же вы, по-моему, недавно говорили, что raw-ptr устарели
TB>Ну если ты пишешь контейнер, в котором сам управляешь памятью, то таки придётся с ними повозиться. TB>Для дерева достаточно юников на потомков и сырого на родителя. Да, сырого на родителя. Да, если он не будет владеть и его время жизни меньше, чем у указуемого объекта, то можно и сырой, ничего не случится.
проблема возникла из : нужно организовать дерево, которое бы можно было сериализовать с помощью библиотеки cereal (она самая лекговесная и удобная из виденных мною). последняя умеет работать только с умными указателями.
и вы что признаете, что raw-ptr все-таки не всегда можно заменить смартами?
Здравствуйте, _hum_, Вы писали:
__>При попытке перевести все на язык смартов возникают трудности: если делать на unique_ptr (что достаточно логично), то непонятно, как быть с указателем на родителя. Если же делать на shared_ptr / weak_ptr, то нарушается логика владения. Как в таком случае быть?
Что конкретно за логика владения нарушается? Вроде, нормально работает.
Если не поможет, будем действовать током... 600 Вольт (C)
Здравствуйте, -MyXa-, Вы писали:
MX>Здравствуйте, _hum_, Вы писали:
__>>При попытке перевести все на язык смартов возникают трудности: если делать на unique_ptr (что достаточно логично), то непонятно, как быть с указателем на родителя. Если же делать на shared_ptr / weak_ptr, то нарушается логика владения. Как в таком случае быть?
MX>Что конкретно за логика владения нарушается? Вроде, нормально работает.
кто владелец-то? что делать с операторами присваивания и констркуторами копирования объектов, содержащих в себе в качестве данных такие деревья, и почему?
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, _hum_, Вы писали:
__>>и вы что признаете, что raw-ptr все-таки не всегда можно заменить смартами?
TB>Да, не везде. TB>Но это не значит, что можно руками фигачить new/delete
Здравствуйте, _hum_, Вы писали:
__>Здравствуйте, -MyXa-, Вы писали:
MX>>Здравствуйте, _hum_, Вы писали:
__>>>При попытке перевести все на язык смартов возникают трудности: если делать на unique_ptr (что достаточно логично), то непонятно, как быть с указателем на родителя. Если же делать на shared_ptr / weak_ptr, то нарушается логика владения. Как в таком случае быть?
MX>>Что конкретно за логика владения нарушается? Вроде, нормально работает.
__>кто владелец-то?
Владелец чего именно?
__>что делать с операторами присваивания и констркуторами копирования объектов, содержащих в себе в качестве данных такие деревья, и почему?
А что бы ты делал при использовании голых указателей?
Если не поможет, будем действовать током... 600 Вольт (C)
Здравствуйте, -MyXa-, Вы писали:
MX>Здравствуйте, _hum_, Вы писали:
__>>Здравствуйте, -MyXa-, Вы писали:
MX>>>Здравствуйте, _hum_, Вы писали:
__>>>>При попытке перевести все на язык смартов возникают трудности: если делать на unique_ptr (что достаточно логично), то непонятно, как быть с указателем на родителя. Если же делать на shared_ptr / weak_ptr, то нарушается логика владения. Как в таком случае быть?
MX>>>Что конкретно за логика владения нарушается? Вроде, нормально работает.
__>>кто владелец-то?
MX>Владелец чего именно?
владелец узлов дерева
__>>что делать с операторами присваивания и констркуторами копирования объектов, содержащих в себе в качестве данных такие деревья, и почему?
MX>А что бы ты делал при использовании голых указателей?
ясно что — делал бы клонирование (в противном бы случае удаление одного объекта привело бы к некорректной работе другого). в случае же с shared клонирование необязательно — два объекта могу работать через шареды с одним и теми же узлами.
Здравствуйте, -MyXa-, Вы писали:
MX>Здравствуйте, _hum_, Вы писали:
__>>кстати, оказывается, std::experimental::observer_ptr
MX>На сколько мне известно, он ничего не делает.
да, так и написано:
It is intended as a near drop-in replacement for raw pointer types, with the advantage that, as a vocabulary type, it indicates its intended use without need for detailed analysis by code readers.
MX> Это просто удобный способ отметить где у тебя, скорее всего, ошибка в программе.
Здравствуйте, _hum_, Вы писали:
__>ясно что — делал бы клонирование (в противном бы случае удаление одного объекта привело бы к некорректной работе другого). в случае же с shared клонирование необязательно — два объекта могу работать через шареды с одним и теми же узлами.
Так это-ж больше от задачи зависит. Надо клонировать — клонируй, не надо — не клонируй.
Если не поможет, будем действовать током... 600 Вольт (C)