Деревянный айтем

[ViTech]

Ну это я тоже знаю Потом неожиданно выяснится что Вы "что-то предлагали", а я никак не смогу вспомнить а что же? 

Я предлагал использовать объектно-ориентированный подход, вместо такого "Си с классами":

Цель - построить структуру для доступа к данным, парент знает своих чайлдов и наоборот. Традиционно это делается членами класса. А в общем случае это граф. Напрашивается напр такое

Код

C++ (Qt)
struct  CTreeItem : public CGraphNode {
  CTreeItem( CTreeItem * parent );
  virtual ~CTreeItem( CTreeItem * parent );
 
  CTreeItem * GetParent( void );
  int GetChildCount( void );
  CTreeItem * GetChild( int index );
  ...
// data
  QString m_name;
  int m_flags;
  ...
};
 

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

Код

C++ (Qt)
struct CGraphNode {
// data
  QVector<CGraphNode *> mArcInp;
  QVector<CGraphNode *> mArcOut;
};

Реализовать это не составляет труда. НО мы взялись делать "в общем виде", стало быть должны хранить всякие-разные зависимости (не только деревянные). По этой же причине "матрица графа" не катит.  Возможно будет создано еще ребро(а) никак не связанные с деревом (см пример с consraints). Как тогда мы будем искать парент/чайлд для нашего айтема?

Но закончится это опять вот так. Так что можно этот этап оптимизировать и не ходить кругами .

[Igors]

Я предлагал использовать объектно-ориентированный подход,

Ну вот опять Вы как-то "предлагали" так что никаких концов не найти 

...вместо такого "Си с классами":

Вы бегло глянули псевдокод и не увидели в нем никакой красивой "семантики". Ни std::forward ни даже std::move! А значит это просто "С с классами", и хорошим этот код быть не может! Увы, такой подход сейчас весьма популярен. Это называется добрым старым словом "пижон" 

[ViTech]

Ну вот опять Вы как-то "предлагали" так что никаких концов не найти 

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

Вы бегло глянули псевдокод и не увидели в нем никакой красивой "семантики". Ни std::forward ни даже std::move! А значит это просто "С с классами", и хорошим этот код быть не может! Увы, такой подход сейчас весьма популярен. Это называется добрым старым словом "пижон" 

Интерфейсов я там не увидел. Разделения функциональности не увидел. Зато увидел, как всё в одну кучу валится. Нравится Вам такой подход - на здоровье .

[Igors]

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

Ну давайте посмотрим что было "в прошлый раз"

В своём примере я не рассматривал методы типа AddKey, DelNthKey и им подобные потому что полагаю, что им не место в том классе, который сейчас называется Curve. На мой взгляд, единственная значимая функциональность "кривой" Curve, которая мелькала в теме - это метод "InterpolateValue( double t )". На основании этого предполагаю, что эта "кривая" нужна для генерации "точки кривой" в заданный момент времени (множества точек в заданный интервал времени с заданным шагом). С этой точки зрения, это уже не кривая, а "генератор" "кривых"/"точек кривых". Как и на основе чего он будет генерировать эти точки - глубоко его личные проблемы и пользователей этого генератора особо волновать не должно. В контексте данной темы получается, что "точки кривой" генерируются на основе "ключевых точек" по заданному правилу (типу сплайна). Опять же, если смотреть с точки зрения функциональной значимости, то есть "интерполятор", который генерирует/интерполирует "точки кривой" в окрестностях "ключевых точек"/"сегменте"/"сегментах". При этом получается, что одна из реализаций "генератора" состоит из набора "интерполяторов".

Далее следует резонный вопрос: и как создавать/изменять все эти "генераторы", "интерполяторы", и самое главное, как туда ключевые точки с параметрами сплайна пихать, особенно если они разного типа могут быть? Это требуется в run-time, поэтому: интерфейс/базовый класс -> реализация и свитч или dynamic_cast до значимого интерфейса/реализации.

Вот эти Curve, о которых в теме говорили, в вашей программе как создаются, заполняются значениями и изменяются? Всё вручную в коде жёстко забито? Или загружаются/сохраняются в файлах, а для редактирования используются какие-то GUI редакторы?

Ну при всем желании никаких конкретных "предложений" я здесь как не видел так и не вижу. Есть какой-то (весьма субъективный, скажем так) взгляд на архитектуру классов, а главное - неуемное (и столь же неуместное) желание разрывать все больше и больше подробностей большого проекта (совершенно гиблый путь).

Впрочем Вы не одиноки. "Привел с пяток реализаций.." недавно звучало. А дальше начинает работать шаблон (или template, не к ночи будь помянут)

Вам сразу ответили..
Ему что ни предложи - все плохо!
Да он просто троллит благосклонно ответивших! (да-да, было и такое)
и.т.п.

Зачем? Ведь Вы же прекрасно понимаете что по существу НИЧЕГО предложено-то не было. Я же никого не обвиняю что мне "не дали правельный ответ", и в свои темы никого на аркане не тяну. Поэтому не надо строить из себя "благодетеля", а из меня "неблагодарную свинью". Это не совсем так  

[ViTech]

Ведь Вы же прекрасно понимаете что по существу НИЧЕГО предложено-то не было. Я же никого не обвиняю что мне "не дали правельный ответ", и в свои темы никого на аркане не тяну. Поэтому не надо строить из себя "благодетеля", а из меня "неблагодарную свинью". Это не совсем так  

А какой "правельный ответ" по существу Вы хотите получить с такой постановкой задачи:

Банальная структурка

Код

C++ (Qt)
struct CTreeItem {
  QString m_name;
  ...
  QVector<CTreeItem> m_child;
 
  CTreeItem * m_parent;
};
 

Вот этот m_parent - иметь его хочется, это делает айтем "самодостаточным" для многих операций.  Но получаем проблемы с копированием. Конечно их можно пережить, но нет ли лучшего решения?

потом что-то про графы, потом вообще трансформируется в:

Два 3D объекта (A и B) могут быть связаны разнообразными "constraint(s)". Это значит что какие-то трансформы объекта A (обычно позиция и поворот) вычисляются автоматычно на основании взаимного положения A и B. Напр задан "AutoLook" constraint, значит A должен "смотреть на B", т.е. автоматычно поворачиваться к нему лицом (ось Z направлена на центр B). Напр юзер передвинул B, и А повернулся к нему.

Вы сначала сами определитесь, что хотите сделать. От уточняющих вопросов Вы отмахиваетесь, типа "это не важно, только отвлекает". Предложенные пути решения Вы пытаетесь развить дальше сами? Или ждёте, когда Вам на блюдечке с голубой каёмочкой преподнесут код, который реализует все Ваши хотелки, которые ещё узнать надо телепатическим способом?

В общем: какой вопрос, такой и ответ .

[Igors]

А какой "правельный ответ" по существу Вы хотите получить с такой постановкой задачи:

Прекрасная постановка. В общем случае есть некоторое "отношение" между объектами, причем очень разных классов. Это может сопровождаться "владением" но совершенно необязательно. Часто это отношение выражается очень стандартными структурами данных (стартовый пост), но часто и нет (пример с constraint). Вот что делать когда таких отношений/связок становится достаточно много? (как у меня). Есть ли смысл это обобщить? Я думаю что да, тогда как? Мне кажется это интересным и достойным обсуждения.

Вам так не кажется? Это Ваше право, и Вы даже можете сказать "да это все фигня!". Хорошо, но не надо повторять это раз за разом, все уже поняли 

Или ждёте, когда Вам на блюдечке с голубой каёмочкой преподнесут код,

Чужой код = то чего надо избегать (а не иметь). Интересно думали ли люди об этом, не исключено что есть и что-то стандартное (какие-то намеки есть в дусте), ведь задача очень общая.

Ну пока дубль-пусто 

[ViTech]

Прекрасная постановка.

Ну да, прекрасная . Давайте ещё раз. Было:

Банальная структурка

Код

C++ (Qt)
struct CTreeItem {
  QString m_name;
  ...
  QVector<CTreeItem> m_child;
 
  CTreeItem * m_parent;
};
 

Вот этот m_parent - иметь его хочется, это делает айтем "самодостаточным" для многих операций.  Но получаем проблемы с копированием. Конечно их можно пережить, но нет ли лучшего решения?

стало:

В общем случае есть некоторое "отношение" между объектами, причем очень разных классов. Это может сопровождаться "владением" но совершенно необязательно. Часто это отношение выражается очень стандартными структурами данных (стартовый пост), но часто и нет (пример с constraint). Вот что делать когда таких отношений/связок становится достаточно много? (как у меня). Есть ли смысл это обобщить? Я думаю что да, тогда как? Мне кажется это интересным и достойным обсуждения.

Кто сможет из "было" вывести "стало", тот, похоже, Вам и поможет, т.к. будет на одной волне . Я не из их числа, телепатические способности у меня так сильно не развиты.

Чужой код = то чего надо избегать (а не иметь).

Пишите тогда свой код. Зачем на форуме что-то спрашивать, если всё равно к этому не прислушиваетесь? Вам говорят, что надо отделять структуру(дерево/граф) от данных, Вы всё равно в одну кучу валите. Говорят, что хорошо бы следить за владением и предлагают механизм, Вы называете это новомодными цацками. Про интерфейсы, архитектуру и прочие высокие материи и вообще говорить не стоит. Вы тогда сразу где-нибудь напишите, что Вам нужно решение без интерфейсов, без умных указателей, без новомодных цацек, без смс, без регистрации .

[Igors]

Кто сможет из "было" вывести "стало", тот, похоже, Вам и поможет, т.к. будет на одной волне . Я не из их числа, телепатические способности у меня так сильно не развиты.

Ну думать о более общем решении программисту приходится частенько, и телепатия здесь ни при чем. Ну если конечно он программист, а не так, "читатель std"

Зачем на форуме что-то спрашивать, если всё равно к этому не прислушиваетесь?

Да к чему "этому"-то? Вы же, пардон, пургу несете 

Вам говорят, что надо отделять структуру(дерево/граф) от данных, Вы всё равно в одну кучу валите. Говорят, что хорошо бы следить за владением и предлагают механизм, Вы называете это новомодными цацками. Про интерфейсы, архитектуру и прочие высокие материи и вообще говорить не стоит.

Да Вы ни одной структуры/класса еще не нарисовали, а уже бегаете с владением и интерфейсами Пожалуйста, разрабатывайте архитектуру, что Вы опять уткнулись во "владение" и очередной вумный указатель?

[ViTech]

Да к чему "этому"-то? Вы же, пардон, пургу несете 
...
Да Вы ни одной структуры/класса еще не нарисовали, а уже бегаете с владением и интерфейсами

В этой теме и другие Вам отвечали, не только я. ssoft в своём первом ответе структуры нарисовал, потом Авварон разжевал так, что подробней уже некуда. Зачем мне повторять их? Сколько людей должны Вам что-то объяснять, чтоб Вы это начали воспринимать? 2, 3, 5, 10?

[Igors]

Сколько людей должны Вам что-то объяснять, чтоб Вы это начали воспринимать?

Ой-ей-ей!  Скажите еще

Я свое время тратил !!!

А потом (с обидой в голосе)

А ты этого не ценишь 

Вот давеча там чего-то было про r/lvalue, std::forward и.т.п. Я же не лезу к людям типа "мужики, кончали бы вы херней заниматься!" (хотя я так и думаю, но оставлю свое мнение при себе). И уж тем более не пытаюсь закрыть кому-то рот типа "Вам уже все объяснили, сколько можно..". Пожалуйста и Вы ведите себя цивильно - не поняли тему или она Вам просто не по вкусу - не лезьте, не липните как банный лист, это просто  "не Ваше", вот и все. Спасибо за понимание

[ViTech]

Ой-ей-ей!  Скажите еще

Я свое время тратил !!!

А потом (с обидой в голосе)

А ты этого не ценишь 

Ого, уже фантазии пошли с моим участием. Что-то мне не по себе становится... Лучше направьте своё воображение в другое русло.

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

Вы в очередной раз вывели меня на чистую воду. Тема же не про "хухры-мухры", а про цельный деревянный айтем! Чтоб работать с такой предметной областью нужна учёная степень не ниже докторской. Куда мне это понять... На том и порешим .

[Igors]

Код

C++ (Qt)
struct CGraphNode {
// data
  QVector<CGraphNode *> mArcInp;  // входные ребра (чайлды CTreeItem)
  QVector<CGraphNode *> mArcOut;  // выходные ребра (парент CTreeItem)
};

Реализовать это не составляет труда. НО мы взялись делать "в общем виде", стало быть должны хранить всякие-разные зависимости (не только деревянные). По этой же причине "матрица графа" не катит.  Возможно будет создано еще ребро(а) никак не связанные с деревом (см пример с consraints). Как тогда мы будем искать парент/чайлд для нашего айтема?

Ну если зависимости "не уникальны" (а всякие-разные), то очевидно нужно их как-то идентифицировать, напр

Код

C++ (Qt)
// (Q)Pair не подходит, второй ключ не нужен
struct CGraphArc {
  ...
  bool operatpr < ( const CGraphArc & other ) const { return m_type  < other.m_type; }
 
// data
  TArcType m_type;
  CGraphNode * m_node; 
};
 
struct CGraphNode {
// примеры геттеров
  CGraphNode * GetInpNode( TArcType type, int index = 0 ) const;  // возвращает чайлда 
  CGraphNode * GetOutNode( TArcType type, int index = 0 ) const;  // возвращает парента 
 
// data
  QVector<CGraphArc> m_ArcInp;  // входные ребра (чайлды CTreeItem)
  QVector<CGraphArc> m_ArcOut;  // выходные ребра (парент CTreeItem)
};
 

Думаю ассоциативные контейнеры (вместо векторов) здесь будет жирновато, да и вставляют они не так как надо, поэтому храним сортированные вектора с вставкой по upper_bound. Да, каждое ребро хранится дважды, ну в этом есть и плюсы (самопроверка). Небольшой недостаток - для связок разных типов невозможно узнать порядок их добавления, ну такой необходимости не видно. Какой ф-ционал обобщается:

1) Разрыв связок при удалении одного их объектов. Тут все хорошо, деструктор CGraphNode вычеркивает ребра

2) Запись связок для undo - возни больше (наверное придется писать индексы m_ArcInp/Out), но вроде тоже ложится

3) I/O - тоже вполне, может даже лучше хранить вектора (данные CGraphNode) отдельно в хеше.

4) (злосчастное) копирование/клонирование. Здесь общего решения не вижу. Смутное соображение - вот если бы как-то создать/заполучить "мапу копирования" (т.е. какой объект скопировался в какой), то можно пробежаться по связкам и заменить.

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

[Авварон]

На первой странице предлагали...

[Igors]

На первой странице предлагали...

Ну считайте что тупой и не понял - лучше чем тратить время на бесполезные пререкания 

4) (злосчастное) копирование/клонирование. Здесь общего решения не вижу. Смутное соображение - вот если бы как-то создать/заполучить "мапу копирования" (т.е. какой объект скопировался в какой), то можно пробежаться по связкам и заменить.

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

1) Объекты A и B копируются в A1 и B1, копии должны иметь те же зависимости (но уже между A1 и B1). Возможный случай но не единственный

2) Связки вообще не копируются.

3) Копируются лишь некоторые связки

Пример: зависимости master-slave, объект slave использует некоторые параметры объекта master'а. Slave(ов) может быть сколько угодно, но каждый ссылается лишь на одного master'а. Фактически "еще одна" иерархия. При копировании slave копия ссылается на того же master'а. А вот при копировании мастера ссылки на него не копируются. Хотя при копировании обоих вариант 1 выглядит разумнее.

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

Да, и если уже "пердлагали" - плиз "ткните носиком" где   Спасибо

[Авварон]

Еще раз - вам надо несколько графов.