Я думаю, что главная проблема здесь в том, что QHash
, будучи хеш-таблицей, ищет значения, хэшируя ключи. Следовательно, необходимо заполнить ключ, чтобы иметь возможность искать значение; "частичного" ключа будет недостаточно - тогда не будет конкретного объекта для хеширования. Аналогичная проблема возникает с картой: для навигации по BST вам нужен полный объект, чтобы делать сравнения и принимать решения влево/вправо. Таким образом, если не возвращаться к чертежной доске и пересматривать свой подход, я бы сказал, поддерживать обратную карту, будь то QHash
или QMap
, с отображением name
-> pair(n_id, a_id)
. Недостатком является то, что вам придется синхронизировать их.
Однако с существующей структурой данных я бы выполнил такой запрос:
#include <algorithm>
QHash<QPair<QString, QString>, QString> info;
QString a_n_id {/*...*/}; // the target N_id
QString a_name {/*...*/}; // the target name
/* ... */
const auto keyList = info.keys(a_name); // QList<QPair<QString, QString> >
std::find_if(keyList.begin(), keyList.end(),
[&](decltype(info)::key_type& key) { return key.first == a_n_id; });
См. этот вопрос на случай, если decltype(info)::value_type
откажется строить на Microsoft VS.
Это, конечно, будет линейным, поскольку, как я уже сказал, хешу нужен полный объект, чтобы иметь возможность выполнять поиск, поэтому в этом случае мы не можем использовать поиск логарифмической сложности.
person
iksemyonov
schedule
16.02.2016
QHash<QPair<QString N_id, QString name>, QString A_id>
, если N_id и имя вместе образуют уникальный ключ? - person iksemyonov   schedule 16.02.2016