у меня два дерева. Одно дерево как структура данных, другое как графическая(treectrl). Деревья одинаковы, те имеют одинаковую структуру и имена. В одном дереве выбран какой-то потомок.

Нужно найти этого потомка в другом дереве. 
Предположим имена в разных ветках могут совпадать, но не могут совпадать 2 ветки одного уровня.те у одного родителя не может быть 2х детей с одинаковыми именами.


мое дерево


що делать.

спецально для таких вопросов создана ветка для новичков

вот я примерно так сделала:


не красиво?

вообще-то это не очень верно. На одном уровне могут быть разные имена, но у разных веток:Уровень одинаковый, имена одинаковые, а ветки разные.
Искать нужно опять рекурсивно. Для этого сначала нужно собрать все имена нодов от текущего до корня (дерева в диалоге). А потом, последовательно выбирать нужные имена в другом дереве.

Кстати, тебе не надоело везде писать std::vector<Node>?.. Может стоит сделать typedef std::vector<Node> Nodes?   

bsa, спасибо. Я предпологала отсутствие совпадений у одного родителя
типа нельзя так:

        рут
нод1   нод1

typedef std сделать надо, но тогда все то исправлять....

Или не полениться, тк нехороший тон?

Вот скажи, тебе не лень писать std::vector<Node> каждый раз? А если потом выяснится, что вместо vector надо использовать map или list? Что делать будешь?
Имхо, делать typedef - это не правило хорошего тона, это просто правило. Потому что рано или поздно могут возникнуть следующие вещи: std::vector< std::list< std::map<std::string, std::vector<std::queue<int> > > > >... попробуй пойми, что автор этого имел в виду  

я организовала успешно поиск одного элемента дерева в другом, но того кто дал мне задание это не устроило

три варианта на выбор было мне предложено.
У каждого элемента дерева должен быть свой идентификатор и этот идентификатор надо связать с каждым элементом в графическом дереве и поиск осуществлять по индивидуальному идентификатору.

либо связывать с каждым элементом дерева графического информацию о участке памяти, где хранится соответствующий узел (что не гуд, тк при ресайзе вектора смещается все на фик). третий вариант - мой, для каждого узла дерева хранить HTREEITEM графического узла (тогда тож искать надо).

Вариант с памятью самый симпотичный в смысле ненужности поиска. В общем что предпочесть и есть ли поле в триконтроле в котором можно хранить некую информацию типа лонг например?

Добавлено через 52 секунды


вот сама деревяшка

вау! оказывается, возможны варианты... а я постеснялся предложить   

это правильное решение. обрати внимание: тебе видимо нужна двунаправленная связь: щелкаем по элементу в treectrl - работаем с деревом в памяти, изменяем дерево в памяти - обновляем treectrl.
Искать нужно в любом случае, либо хранить обе ссылки. Однако это вид должен все знать про документ, а не наоборот. Так что присваиваем идентификаторы узлам дерева и храним их как ссылки в treectrl.
Производительность: когда манипулируем с treectrl (пользователь щелкнул на элементе) скорость неважна, т.к. пользователь 0.1 сек всегда подождет.
Когда обновляем treectrl - стараемся это делать редко, когда все операции завершены и, возможно, просто перестраиваем treectrl - тут искать не надо, просто обходим.

есть. ищи SetItemData/GetItemData

Добавлено @ 22:19
PS. Тебя явно одновременно воспитывают и проверяют, и вообще ведут себя грамотно   
Не расслабляйся  

Добавлено @ 22:23
PPS Помню года 3-4 назад пришлось оптимизировать фрагмент кода: прога тормозила в процессе расчета. Оказалось: было дерево ~100 узлов, при этом было примерно ~1000000!! обращений в дерево. А дело было в том, что данные хранилось непосредственно в treectrl, никакой доп. информации не было, и при необходимости получить нужный узел производился последовательный просмотр содержимого дерева...   

Это сообщение отредактировал(а) baldina - 19.3.2008, 22:25

tonchitos, в качестве идентификатора уже служит имя нода (у тебя же дети одного нода не могут носить одно имя, так?)... И именно этот способ я предлагал использовать в пред-предыдущем своем сообщении (я его довольно невнятно сформулировал, правда). Ты каждый элемент графического дерева ассоциируешь с именем нода в памяти, а поиск производишь рекурсивно:Ну сделай наконец typedef для std::vector<Node> (твой работодатель тебе дополнительный плюс поставит за это)!!!
И тебе точно нужно поле level? Я так понимаю, особой смысловой нагрузки оно не несет.

bsa,  имя нода не катит оказывается   , мне сказали что могут совпадать имена сколько влезет. Поэтому нужен идентификатор.


baldina, спасибо. У меня как раз задача - предполагается что дерево очень большим будет, поэтому все дерево не буду загружать, велели найти ф-ии или контрл где нажатие плюсиков (разворот-сворот чайлдов) можно отследить, тогда при нажатии на плюсик потомки будут загружаться в контрл, при закрытии плюсика - выгружаться. 
Мне нужно отслеживать че с плюсиками делают, плюс задавать для каждого чайлда отображать их или нет.

Уходя с работы я еще поговорила и от моих трех вариантов один остался.


этот вариант мне предложили сами, но не одобряют тк память. Люди, если ресайза избежать можно быть за память уверенной? Фиг его знает как там вектор шалит.

вариант отмели, тк у каждого дерева может быть несколько графических деревьев. воть.

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

В итоге катит первый вариант с идентификаторами. Возможен второй, но под вопросом. 

теперь новый момент:

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

варианты.



и потом :

GUI::Node node;
GUI::Root root;
.................
................
root.childs.resize(n);
и так работать

но чего то мне не нравится. Работаем с рутом, а методы используем нода.

Тогда лучше отнаследовать?

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

Добавлено через 36 секунд
bsa, тайпдеф сделаю!!!! утром займусь этим обязательно.

Я не понял, у одного нода могут быть чилды с одинаковыми именами?
На память завязываться очень плохо (особенно, при использовании векторов). С идентификаторами тоже есть сложность - как их генерировать (вариант "статический счетчик" имеет ограничение на количество значений, например)... Хотя можно перейти с векторов нодов на вектора указателей на ноды, тогда можно будет использовать "память"... Но возникнут некоторые сложности при удалении нодов (придется следить за этим и делать соответствующие действия с графическим деревом).

В данном случае рут просится быть наследником нода. Хотя, если тебе нужно следить за обращениями к нодам, то лучше использовать не наследование, а агрегацию (включение), но те так как у тебя сделано:В данном случае, в getNode() можно запихать уже фиксирование того, к кому происходило обращение...

typedef сделать не так уж и сложно (Правка - Найти и заменить: "std::vector<Node>" на "Nodes", а потом добавить в класс typedef std::vector<Node> Nodes; - и всё).

в руте нужно пока хранить тока последнее значение... эмс, а можно поподробнее про агрегацию 

tonchitos, у меня в последнем примере сделана агрегация.   

сорри, не оч поняла смысл гетНода... Объясните плиз. 

Добавлено через 2 минуты и 11 секунд
class Root
{
public:
      Root()
      {
      }
      ~Root()
      {
      }
      const Node& getNode() const 
      { 
          return node; 
      }
      Node& getNode() 
      { 
          return node; 
      }
private:
      Node node;
      long lastIdent; // как предполагается менять его, если у меня в ноде по идее меняться должен и не в ноде тоже
};